Re: If-Match and Weak ETags

(I am just repeating the same issue…): this looks like a non-editiorial change to me. Ie, may lead to a new CR round.

I am not an expert, cannot judge this. But, at this moment, this seems like an issue raised for the LDP errata; is there evidence that this is accepted as an LDP erratum in the first place? Our dependency on LDP means that deciding to change something ourselves, thereby breaking our dependency on LDP, is also a problem, isn't it?

Ivan


> On 24 Aug 2016, at 21:34, Benjamin Young <byoung@bigbluehat.com> wrote:
> 
> Could we flip it to use `If-None-Match`? That MUST use week comparison:
> https://tools.ietf.org/html/rfc7232#section-3.2 <https://tools.ietf.org/html/rfc7232#section-3.2>
> 
> `If-Match` is certainly more common in the case of PUT’s and such. However, given that we’re updating a Resource and *not* it’s representation (at least not byte-for-byte in most cases), then `If-None-Match` seems to do the trick.
> 
> Adding date related requirements to PUT and DELETE feels race-condition prone (not to mention just plain bothersome and hard to handle at scale). :-/
> 
> Thoughts?
> 
> 
> --
> http://bigbluehat.com/ <http://bigbluehat.com/>
> http://linkedin.com/in/benjaminyoung <http://linkedin.com/in/benjaminyoung>
> 
> From: Robert Sanderson <mailto:azaroth42@gmail.com>
> Sent: Sunday, August 21, 2016 5:08 PM
> To: Web Annotation <mailto:public-annotation@w3.org>
> Subject: Fwd: If-Match and Weak ETags
> 
> 
> A bug in LDP that affects us to some degree is described below.  Basically -- the current HTTP RFC requires strong ETags with If-Match.  Strong ETags MUST change when the representation changes. Thus the representation of the Annotation would need to be byte for byte identical, which is very hard to ensure when generating from an RDF triplestore and order of the triples is indeterminate.
> 
> For our uses, given that we recommend a very specific JSON-LD serialization, the issue does not affect us to the same degree as a generalized LDP implementation.   However ... the solution of using If-Modified-Since would get us out of the bind for systems that are built on triplestores and couldn't guarantee the order of the properties in an object, for example.
> 
> Rob
> 
> ---------- Forwarded message ----------
> From: Tom Johnson <tom@dp.la <mailto:tom@dp.la>>
> Date: Mon, Aug 15, 2016 at 12:44 PM
> Subject: If-Match and Weak ETags
> To: LDP Next <public-ldpnext@w3.org <mailto:public-ldpnext@w3.org>>
> 
> 
> A couple of us have run into an issue with the ETag expectations of LDP, and are hoping that some discussion can resolve the issue.
> 
> The LDP specification (4.2.4.5)[0] has a few SHOULDs relating to client and server use of `If-Match` headers; namely, that clients SHOULD use them on modification, and that servers SHOULD require their use.
> 
> RFC 7232 (sec. 3.1)[1] states that "An origin server MUST use the strong comparison function when comparing entity-tags for If-Match" (RFC 2616 contains the same restriction).
> 
> These two clauses seem to recommend that a server SHOULD generate strong ETags for its resources---I don't believe a server can respect the recommendation of 4.2.4.5 any other way.
> 
> As far as I know, no one has implemented strong ETags for content negotiable RDF resources. Short of caching all responses between updates, I'm not sure it's possible for an LDP server backed by a triplestore to make the relevant guarantees about the representations it returns.
> 
> For clients, given that LDP servers are normally returning weak ETags, using `If-Match` is not a serious option (a weak etag will never match in strong comparison).
> 
> Should LDP servers ignore 4.2.4.5? Can we recommend an alternate pattern for verification (`If-Unmodified-Since`)?
> 
> As further background, a key point of discussion in the LDP WG's handling of this a thread from Feb. 2013.[2]  The message linked refers to ignoring RFC 2616, based on a then current draft of 7232. This suggests to me that LDP is genuinely giving bad (out of date) advice, here.
> 
> Best,
> 
> Tom
> 
> [0] https://www.w3.org/TR/ldp/#ldpr-put-precond <https://www.w3.org/TR/ldp/#ldpr-put-precond>
> [1] https://tools.ietf.org/html/rfc7232#section-3.1 <https://tools.ietf.org/html/rfc7232#section-3.1>
> [2] https://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0035.html <https://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0035.html>
> 
> 
> 
> 
> 
> --
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704