W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: i107

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 28 Jul 2008 16:56:24 +0100
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <1377925A-8446-4E0A-88CF-23C16387285D@mnot.net>
To: Brian Smith <brian@briansmith.org>


On 28/02/2008, at 5:53 AM, Brian Smith wrote:

[ second representation corrected as per your later mail ]

>
> Consider a resource http://example.org/a with two representations,  
> where the server varies the representation based on Accept-Encoding:
>
> Last-Modified: Wed, 15 Nov 1995 06:00:00 GMT
> ETag: 1
> Content-Type: text/plain
> Vary: Accept-Encoding
>
> Last-Modified: Wed, 15 Nov 1995 12:00:00 GMT
> ETag: 2
> Content-Type: text/plain
> Content-Encoding: deflate
> Vary: Accept-Encoding
>
> Now, consider the following requests. What is the best status code,  
> and which entity (if any), ETag, and Last-Modified should be  
> returned for each request?
>
> (a) GET http://example.org/a HTTP/1.1
>    If-None-Match: 1
>    Accept-Encoding: deflate
>
>    HTTP/1.1 304 Not Modified
>    ETag: 2
>    Vary: Accept-Encoding

That's utterly confusing. The client asked to validate etag "1" and  
you told them that it wasn't modified, but returned an updated ETag  
and didn't say whether or not the entity is encoded.

13.3.4:
> An HTTP/1.1 origin server, upon receiving a conditional request that  
> includes both a Last-Modified date (e.g., in an If-Modified-Since or  
> If-Unmodified-Since header field) and one or more entity tags (e.g.,  
> in an If-Match, If-None-Match, or If-Range header field) as cache  
> validators, MUST NOT return a response status of 304 (Not Modified)  
> unless doing so is consistent with all of the conditional header  
> fields in the request.


> (b) GET http://example.org/a HTTP/1.1
>    If-None-Match: 1
>    Accept-Encoding: deflate;q=0
>
>    HTTP/1.1 304 Not Modified
>    ETag: 1
>    Vary: Accept-Encoding

See above.


> (c) GET http://example.org/a HTTP/1.1
>    If-None-Match: 2
>    Accept-Encoding: deflate
>
>    HTTP/1.1 304 Not Modified
>    ETag: 2
>    Vary: Accept-Encoding

OK

>
>
> (d) GET http://example.org/a HTTP/1.1
>    If-None-Match: 2
>    Accept-Encoding: deflate;q=0
>
>    HTTP/1.1 304 Not Modified
>    ETag: 1
>    Vary: Accept-Encoding

See above.

[ etc. ]


>
>
> (e) GET http://example.org/a HTTP/1.1
>    If-None-Match: nothing-matches-this
>    Accept-Encoding: deflate
>
>    HTTP/1.1 200 OK
>    ETag: 2
>    Vary: Accept-Encoding
>
>    (the response entity is variant 2)
>
> (f) GET http://example.org/a HTTP/1.1
>    If-None-Match: nothing-matches-this
>    Accept-Encoding: deflate;q=0
>
>    HTTP/1.1 200 OK
>    ETag: 2
>    Vary: Accept-Encoding
>
>    (the response entity is variant 1)
>
> Now, make the following substitutions:
>
> * replace: "If-None-Match: 1"
>  with:    "If-Unmodified-Since: Wed, 15 Nov 1995 06:00:00 GMT"
>
> * replace: "If-None-Match: 2"
>  with:    "If-Unmodified-Since: Wed, 15 Nov 1995 12:00:00 GMT"
>
> * replace: "If-None-Match: nothing-matches-this"
>  with:    "If-Unmodified-Since: Wed, 15 Nov 1995 00:00:00 GMT"
>
> What should the results be? I believe they should be exactly the  
> same as the ones I gave above, except (a) and (b) MAY return the  
> same results as (e) and (f), since one of the variants was modified  
> since the given time ("Wed, 15 Nov 1995 06:00:00 GMT").
>
> I think this demonstrates that If-[Un]modified-Since validation  
> needs to be changed to be more like the current ETag validation, and  
> not the other way around.
>
> - Brian
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Monday, 28 July 2008 15:57:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:53 GMT