Re: If-Match and Weak ETags

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
>
>
>