ETag might need a weak validator instead

[RubenVerborgh]

[acoburn]

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?

[kjetilk]

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.

[acoburn]

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)

[csarven]

Reopening the issue as it was closed by a non-CG member at the time, without CG's consent. The last useful revision in #340 (comment) is below, before the comment was erased.

---

Background

For simplicity, let me briefly recap weak and strong validators from RFC7231:

+--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match |
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+

Problem

The current Protocol document reads:

Servers MAY use the HTTP ETag header with a strong validator for RDF bearing representations in order to encourage clients to opt-in to using the If-Match header in their requests.

However, in CommunitySolidServer/CommunitySolidServer#1036, we found out that strong validators can pose problems.

Concretely, we found that proxies such as NGINX might change a strong ETag into a weak one when they perform certain actions such as compressing the body. So while the actual Solid server sends:

etag: "1635520727000"

the proxy turns this into

etag: W/"1635520727000"

Solutions

A first reflex could be: why don't we let the server send a weak ETag?
But, as the table above shows, this means that strong comparison would always fail!

So looking at the table rows, the only option seems to be that the server performs weak comparison.

[csarven]

GitHub's ToS allow users to reference and reuse publicly available comments within GitHub (see Section D.5). And, the Solid GitHub org operates under an MIT license, promoting open collaboration and transparency. Additionally, as part of the Solid CG, contributions fall under the W3C Community Group CLA, which permits broad reuse within the community.