[mdx] mdq issue #9: etag in conditional GET

[Ian Young]

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>