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

On Wed, 30 Jan 2008, Brian Smith wrote:

> Mark Nottingham wrote:
>> 10.2.2 (201 Created):
>>> A 201 response MAY contain an ETag response header field indicating
>>> the current value of the entity tag for the requested variant just
>>> created, see section 14.19.
>> I find this just plain weird. On POST responses, it implies
>> that you can negotiate for response headers on another
>> resource and get them tunnelled back in the current response.
>> If there's a Vary header present, does it apply to that
>> resource too? If not, how do you know what the requested
>> variant really was?
>
> Also, look at AtomPub (RFC 5023). When you post anything with a type
> other than application/atom+xml, you end up creating TWO resources with
> one request. I've always thought that "ETag" stood for "Entity Tag", and
> thus applied to the response entity.

ETag is a response header and not an entity header (and yes, it is really 
confusing), so when you have a CL and an ETag for the same entity, you 
can't link the two, as it relates only to the Request-URI, even if it 
seems logical to do so.

The definition of 201 assumes that only one resource is created, so if a 
POST creates multiple new resources, 200 should be returned instead of 
201. However, in the text:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-01#section-9.2.2
<<<
The response SHOULD include an entity containing a list of resource 
characteristics and location(s) from which the user or user agent can 
choose the one most appropriate.
>>>
Should we keep this "multiple locations for one resource" paradigm?

> When I POST something, I will get a response with an entity in it. The
> entity will be some kind of document that describes the resource(s) I
> created with the post. If the server also created a resource that
> contains the same information as the response entity, then it will
> include a Content-Location header. The Content-Location header means
> something like "this is where you can retrieve (a variant of) the
> response entity." If there is no Content-Location, then there is no
> obvious way to retrieve (a variant of) the response entity if you forget
> it.

And if you GET a resource like http://www.example.com/foo/ , edit it and 
want to do a PUT, most of the time you'll fail because chances are high 
you don't have a CL indicating you are editing 
http://www.example.com/foo/index.fi.html (or at list you intend to do 
this)

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 31 January 2008 09:49:05 UTC