Re: If-Match and Weak ETags

> On 21 Aug 2016, at 23:07, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> 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.
> 

Can we "simply" defer to the discussion in LDP land? Ie, should we define this ourselves, or can we just rely on LDP however they decide this will be done?

Ivan


> 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