[mdx] mdq issue #9: etag in conditional GET
Ian Young
ian at iay.org.uk
Thu Jun 12 10:21:18 PDT 2014
Hi all,
I've subscribed Mads Freek Petersen to the list. At the recent REFEDS meeting, he passed me a comment about the mdq specification. Here's what he says:
> In 4.2 it says:
>
> Upon a successful response the responder MUST return an ETag header
> and MAY return a Last-Modified header as well. Requesters SHOULD use
> either or both, with the ETag being preferred, in any subsequent
> requests for the same resource. In the event that a resource has not
> changed since the previous request, the requester will receive a 304
> (Not Modified) status code as a response.
>
> As the ETag is always provided using the Last-Modified for subsequent
> requests is actually not allowed as per RFC2616 so the possibility of
> using Last-Modified should be removed. This is in sync with the
> wording in 2.6:
> …
>
> A metadata request to the same URL, after an initial request, MUST
> include the following header per
> section 13.3.4 of RFC 2616 [RFC2616]:
>
> If-None-Match
Any other observations on this?
Note that I've also recently opened an issue #10 on the fact that the official definition of HTTP/1.1 is now a new set of RFCs issued just this month, replacing RFC 2616. So those are probably the right place to look for definitive answers. Here's a blog entry on this change:
https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead
Enjoy,
-- Ian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20140612/510440e0/attachment.bin>
More information about the mdx
mailing list