Re: If-Match and Weak ETags

Although we have yet to decide on a date for the next LDP-Next meeting, I
would like to propose that we include this issue of Weak ETags and If-Match
to the agenda:
https://www.w3.org/wiki/LDP_Next_Community_Group#Next_Meeting

Regards,
Andrew

On Sat, Aug 20, 2016 at 9:15 PM, A. Soroka <ajs6f@virginia.edu> wrote:

> Is there a process available to this group in which we can assemble errata
> for consideration by the original LDP working group? Or can we publish a
> note on this topic on our own account? Speaking under my implementor's hat
> (Fedora Commons) this is a very practical issue. We have users asking today
> how we expect to deal with concurrency in light of this bind.
>
> ---
> A. Soroka
> The University of Virginia Library
>
> > On Aug 16, 2016, at 10:49 AM, Benjamin Armintor <armintor@gmail.com>
> wrote:
> >
> > For what it's worth, I don't see another way to reconcile RFC 7232 and
> LDP 1.0 besides using If-Unmodified-Since. The spec is out of joint with
> HTTP 1.1.
> >
> > Regards,
> >
> > Ben
> >
> > On Mon, Aug 15, 2016 at 3:44 PM, Tom Johnson <tom@dp.la> wrote:
> > 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
> >
> >
> >
>
>
>