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: Brian Smith <brian@briansmith.org>
Date: Thu, 14 Feb 2008 09:51:58 -0800
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <005801c86f32$4bad36b0$6501a8c0@T60>

Julian Reschke wrote:
> Brian Smith wrote:
> > Julian Reschke wrote:
> >> Brian Smith wrote:

> > I base my statement on "The Accept request-header field can 
> > be used to specify certain media types which are acceptable
> > for the response" and many other similar statements in
> > sections 14.1-5. Clearly, the intent is that the
> > Accept-* headers always specify the client's preferences 
> > regarding the response entity.
> 
> Agreed. The question is whether they *also* select a 
> representation, before the response entity is generated.
> 
> If we do not do that, we'll have to distinguish between 
> headers selecting a representation, and those selecting the 
> format of a status message. Which seems like a bad idea to me.
> 
> > Is this set of proposals intended to define how to edit a specific 
> > representation of a content-negotiated resource? I think it 
> > is pretty clear how it works when each separately-editable
> > representation has its own URI (see below about Content-Location).
> > Why isn't that good enough?
> 
> I think it is good enough, and we shouldn't try to do more.

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"? 

> > 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? 

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?

- Brian
Received on Thursday, 14 February 2008 17:52:04 GMT

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