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

Re: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 14 Feb 2008 19:05:43 +0100
Message-ID: <47B482F7.9080909@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: 'HTTP Working Group' <ietf-http-wg@w3.org>

Brian Smith wrote:
> If you don't want to define a new mechanism for editing specific
> representations, then why do you need to "select a representation before
> the response entity is generated"? 

Because I'd like "selected representation" to be independent of request 

>>> Also, if I POST with "Accept: image/jpg;q=1.0, 
>>> image/png;q=0.9" to an AtomPub collection, should I expect
>>> the AtomPub collection to return a "406 Not Acceptable"
>>> response, since the collection does not have a 
>>> JPEG or a PNG representation?
>> That would be consistent with what I propose.
>> Why would you POST with that Accept header, btw?
> I messed the example up. If I POST with "Accept:
> application/atom+xml;type=entry" then can the server respond with "406
> Not Acceptable" since the collection (at the Request-URI) has type
> application/atom+xml;type=feed? 

406 doesn't seem to allow that:

"The resource identified by the request is only capable of generating 
response entities which have content characteristics not acceptable 
according to the accept headers sent in the request." -- 

So the error condition applies to the process of generating the 
response, not selecting a representation.

> If I PUT to an image's location with "Accept: text/html", can the server
> respond with "406 Not Acceptable" since it doesn't have an HTML
> representation of the image? How could the client say it wanted status
> messages in HTML while editing an image?

See above.

Which doesn't mean I am happy with how things are -- but that's why we 
are having this discussion. (And we have it because the RFC2616 term 
"requested variant" doesn't work well with anything except HEAD/GET).

BR, Julian
Received on Thursday, 14 February 2008 18:06:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC