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>
Date: Mon, Aug 15, 2016 at 12:44 PM
Subject: If-Match and Weak ETags
To: LDP Next <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
[1] https://tools.ietf.org/html/rfc7232#section-3.1
[2] https://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0035.html





-- 
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049