Is support for RFC7232 Conditional Requests mandatory?

[RubenVerborgh]

[kjetilk]

Indeed, every MUST can be expensive, but my opinion is that to have sufficient performance in a decentralized system, we have to enable caches in every way we can. I definitely think we should have a MUST there.

[kjetilk]

Right!

The way I see caching is that there are essentially three directions:

1. Conditional requests,
2. Caching given by resource managers as a commitment (with e.g. Cache-Control: max-age= ),
3. Notifications of changes to be explicit that caches should be invalidated.

Notifications is future work, RFC7234 is hard to get commitments for, so conditional requests is really the low-hanging fruit.

Then atomicity is another important reason to do it, but it also requires strong validators as per the spec, and that does not sit very well with RDF, because we can have several semantically equivalent representations. We could look into a third class of validators for this purpose.

RFC7234-based caching could be enabled in some cases (e.g. chat logs that after a day become immutable), but in general, much UX work should go into helping people state their expectations for future validity. Only when we get to that point are we ready to state the case for that more strongly.

[kjetilk]

It would be stretching the spec a bit since it is explicitly for differentiating between different representation of the same resource... I do believe that this stretching is appropriate, but I also believe we need to be careful about how we do it, and that a new type of validator is an approach that should be explored.

[michielbdejong]

Just an organizational note, we might want to keep spec (semantics) issues in https://github.com/solid/solid-spec/issues and keep the issues list in this repo strictly for rewrite (syntax) issues.

[michielbdejong]

OK, so are there any issues that we should still file at the current spec, or should we just say the solid-spec repo is frozen, and move to this issue tracker?

[kjetilk]

Also link #60 .

[csarven]

I wonder if we can get away with a SHOULD

I don't see the direct connection between having PATCH available (let's say as MUST .. pending #39 #85 .. ) and changing server's RFC7232 from MUST to SHOULD. Or if/how they can be interchangeable - not sure if that's what you're hinting at. My understanding is that, they can address different things.

I think having RFC7232 as a MUST for servers is relatively a low-hanging fruit. Worth to emphasise that the current TSE doesn't have any requirement for a client. So, there is no particular guarantee to reach the performance that's seeked (in this discussion). Depending on the degree we want to achieve that, we may need to actually state and bump client's requirements as well.

I would also note that RFC7232 doesn't have to be all or nothing - although that'd be simple to get across. Alternatively, we can pick and choose e.g If-Match and If-None-Match is a MUST for both servers and clients. (I'm not arguing for the details here.. just stating an approach).

[csarven]

Noting here that LDP already mentions If-Match and ETag as SHOULDs for PUT.

[JordanShurmer]

I am in favor of RFC7232 being a MUST for solid.

LDP already enforces Etag support, and forces servers to honor If-Match header specifically on PUT requests, so Solid would simply be expanding it to the rest of 7232.

LDP:

Etag is explicitly enforced:

4.2.1.3 LDP server responses must use entity tags (either weak or strong ones) as response ETag header values, for responses that contain resource representations or successful responses to HTTP HEAD requests. [ldp](https://www.w3.org/TR/ldp/#h-ldpr-gen-etags]

Servers MUST check If-Match conditional requests when clients use them on PUT:

LDP servers must respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request ldp