I hadn’t thought about this before, but it does seem like a general question about http rather than solid specifically. We want to guarantee integrity of all http requests.
Here’s one explanation:
Solid also uses etags to ensure the right version is being updated, and here’s a discussion of some of the complications with rdf specifically:
opened 08:57PM - 20 Sep 19 UTC
closed 08:01AM - 03 Aug 20 UTC
topic: resource access
The LDP specification [requires the use of ETag headers](https://www.w3.org/TR/l… dp/#ldpr-gen-etags) for `GET` and `HEAD` responses. There is some subtlety to how ETags work in the context of RDF, and some implementation guidance (e.g. in a non-normative section) might be useful.
For example, [RFC 7232, section 2.3](https://tools.ietf.org/html/rfc7232#section-2.3) is clear that different ETags should be produced for different representations of a resource:
> An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both.
Furthermore, [RFC 7232, section 2.1](https://tools.ietf.org/html/rfc7232#section-2.1) describes the difference between weak and strong ETags. For RDF serializations where RDF semantics may be more important than byte-for-byte consistency, is it legitimate to generate a strong ETag for an LDP-RS even if the server does not guarantee the order of the triples?
Consider also the case where a server can produce `text/turtle`, `application/ld+json` and `application/n-triples`, each of which generates a different ETag value. Then consider also that the server supports `Prefer` headers as well as `Content-Encoding` negotiation, each of which could produce an additional dimension for ETag generation. In that case, suppose a client wishes to send a `PATCH` request along with an `If-Match` header as part of a conditional request. What value should be included in the `If-Match` header? And given the various permutations of ETags that could be generated, does a server need to check all such permutations before accepting the conditional request? (Does `If-Match` make sense in the context of `PATCH`?)
This question is simpler in the context of `PUT`, but what if a client retrieves an LDP-RS as JSON-LD using a custom profile (`Accept: application/ld+json; profile="https://...."`), modifies the RDF graph and then, via `PUT` replaces the resource as JSON-LD. What value should be used with `If-Match`? Does this change if the resource is retrieved as JSON-LD and replaced as Turtle?
There are clearly some nuances here, and it may be helpful to provide some guidance to implementers.