- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 14 Feb 2008 19:05:43 +0100
- 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 methods. >>> 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." -- <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.4.7> 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