Re: i107

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.

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

b) define the set of representations that conditional requests apply  
to on a per-method basis.

Neither of these options seems desirable to me, but I'd like to hear  
what others think.

This is somewhat related to both issues 22 and 69, btw.



On 28/07/2008, at 4:25 PM, Brian Smith wrote:

> Mark Nottingham wrote:
>> Julian and I were just discussing this (alas, not yet over a
>> Guinness).
>>
>> I think the right thing to do here is to describe both
>> variant selection (p3, section 5.1, p6, 16.5) and validator
>> comparison (p4 section 5) in terms of set theory (at least
>> informally), so that the set of representations available for
>> a given request is the intersection of those selected by
>> negotiation and those requested conditionally.
>>
>> Make sense?
>
> No, because content negotiation only effects the form of the response
> entity, which isn't even a representation of the resource for most  
> kinds of
> request. In particular, you cannot use Accept-* headers to narrow  
> the scope
> of a PUT/POST/DELETE request to change only particular variants of the
> resource, and the server continue to be free to ignore any or all  
> request
> header fields (Accept-* in particular) unless RFC 2616 specifically  
> requires
> them to not be ignored (e.g. If-* headers, sometimes Content-*  
> headers).
>
> A long time ago I listed some simple examples of how conditional  
> requests
> and content negotiation must interact for the most common case we have
> today, namely Vary: Accept-Encoding. See
> http://article.gmane.org/gmane.ietf.http-wg/795. I am really  
> interested in
> getting feedback from those examples.
>
> Here is another example, where /some-image has two representations:
> image/png (ETag: "png-1") and image/gif ("gif-1"):
>
> PUT /some-image HTTP/1.1
> Content-Type: image/png
> If-Match: "gif-1"
> Accept: text/html
>
> The client downloaded the GIF variant previously but is uploading a  
> PNG. As
> far as content-negotiation is concerned, its only preference is that  
> the
> status message in the response entity should be in HTML if possible;  
> the
> Accept header isn't saying anything about the representations of the
> resource. The only way the server can reasonable handle this request  
> is by
> considering the ETags of all representations of the resource when  
> processing
> the If-Match header field.
>
> Regards,
> Brian
>


--
Mark Nottingham     http://www.mnot.net/

Received on Monday, 28 July 2008 15:57:09 UTC