RE: i107

Mark Nottingham wrote:
> I don't agree that that's the only reasonable way to handle 
> the request; another would be to send a 412 -- i.e., send the 
> etag for the representation you're trying to upload.

I disagree. If the server returns a 412, I am going to issue the same
request that got me the GIF representation in the first place:
    GET /some-image HTTP/1.1
    
And the server is required to respond with the GIF unless it had returned
"Vary: *":
    HTTP/1.1 200 OK
    ETag: "gif-1"
    Content-Type: image/gif
    ...

No progress will have been made. It is unreasonable to expect the Accept-*
headers (if any) of some previous GET request to somehow be aligned with the
Content-* headers of a subsequent PUT request. It isn't obvious to me that
it is even possible to do so in every case.

> If we want to support the case that you're talking about, it 
> seems to me that we'd either need to:
> 
> a) Allow a cache to return a response which doesn't match 
> selecting headers. For example, if a cached response has:
> 
> Vary: Accept-Encoding ; request had 'gzip'
> ETag: "123"
> 
> and a request comes in with
> 
> Accept-Encoding: deflate
> If-None-Match: "123"

> the cache would be allowed to return it (doesn't make much sense), or

The cache has to forward the request on because the Accept-Encoding header
doesn't match and Accept-Encoding was listed in the Vary header. If the
origin server returns a 304 with an ETag: "123" then the cache can indeed
return a 304 with ETag: "123" just as the origin server would. If the client
request was not conditional, then it indeed could return the representation
with ETag: "123" even if the encoding doesn't match (the origin server chose
to ignore the Accept-Encoding header, so the cache can too). In the future,
the cache will be able to return the representation with ETag: "123"
whenever the Accept-Encoding header is "gzip" or "deflate", since that is
what the origin server does.

Cheers,
Brian

Received on Monday, 28 July 2008 16:36:27 UTC