solid
ETag might need a weak validator instead
Having the server perform weak comparison in this case would deviate from RFC 7231.
Quoting from section 3.1
An origin server MUST use the strong comparison function when comparing entity-tags for If-Match (Section 2.3.2), since the client intends this precondition to prevent the method from being applied if there have been any changes to the representation data.
In other words, according to RFC 7231, sending a write request with a weak ETag must always fail.
Is this more of an issue with the proxy changing the ETag?
Edit: alternatively, is this more of an issue of Solid's needs not entirely matching the semantics of ETags? Should there be consideration of alternative methods for performing conditional writes?
Is this more of an issue with the proxy changing the ETag?
Perhaps it is; I will check if this can be avoided. We should definitely document this if that's the case.
I have switched gzip compression off on my proxy for now, so my strong ETags are back.
is this more of an issue of Solid's needs not entirely matching the semantics of ETags?
Perhaps; there seems to be no point for a client to send a weak ETag within If-Match. Maybe this is the real issue.
But it would be nice to have this fixed at the proxy level nonetheless.
I have a vague memory of the three of us discussing this F2F a very long time ago....?
And I think we found that this is hard, because neither really fits with RDF that can have multiple different serializations where what you care about is not the expressed representation, but the graph that is expressed... I think we concluded we need another type of validator beyond strong and weak...
It seems like if we get a digest of the graph, as is one of the use cases of Linked Data Signatures (or whatever it ended up being named), that digest could also be reused for such a validator. Though that may also be overkill, we probably wouldn't need a cryptographically strong validator anyway...
Meanwhile, I'm really conflicted about what we should use.
this is hard, because neither really fits with RDF [...] I think we concluded we need another type of validator
Yes, indeed!
It seems like if we get a digest of the graph, as is one of the use cases of Linked Data Signature
For reference, the most common mechanism (that I'm familiar with) used for generating RDF digests is built on URDNA2015 and it is described at https://json-ld.github.io/rdf-dataset-canonicalization/spec/ (there are some pathological edge cases, so we'd want to be careful about using this as a general mechanism)