Is support for RFC7232 Conditional Requests mandatory?

[RubenVerborgh]

No description provided.

[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.

[RubenVerborgh]

we have to enable caches in every way we can

Okay, but:

• we should distinguish between RFC7232 for caching (= GET/HEAD) and semaphores (= other methods); your answer currently only pertains to the first
• RFC7234 is currently a SHOULD

[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.

[RubenVerborgh]

and that does not sit very well with RDF, because we can have several semantically equivalent representations

As long as the ETag is not tied to a specific representation, we should be fine?

[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.

[RubenVerborgh]

True, I had misread

A strong validator is unique across all versions of all representations associated with a particular resource over time.

[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.

[RubenVerborgh]

@michielbdejong This specific issue came up due to the rewrite. solid/spec does not even mention conditional requests; v0.8 has thus no opinion about whether or not RFC7232 should be there.

As I've argued before, this rewrite is necessarily more than just syntax/grammar. That is because v0.8 is too vague and high-level, and it does not even get to issues like this one. This issue came up because we write the text at a much more detailed level, so some details that were not expressed in v0.8 now need to be discussed.

[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?

[RubenVerborgh]

are there any issues that we should still file at the current spec

Probably only important bugs like #31 (comment)

should we just say the solid-spec repo is frozen, and move to this issue tracker?

For all other purposes, I would say yes.

[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

[csarven]

Coming back to the original comment: Solid servers should be required to implement RFC 7232 because currently there is no rule for mutating non-RDF resources with PATCH. Hence, for Solid servers to support conditional requests on any resource, MUST is necessary for interop.