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: Wed, 30 Jan 2008 17:54:23 -0800
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <003601c863ac$3d62a9a0$0501a8c0@T60>

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.

Also, what happens when you POST a multipart document with 10 parts, and
the server creates 20 different resources from it, but doesn't create a
resource to represent the 10 parts grouped together? (Also, what do you
put in the Location header in this case?)

> 14.14 (Content-Location)
> > The Content-Location entity-header field MAY be used to supply the 
> > resource location for the entity enclosed in the message when that 
> > entity is accessible from a location separate from the requested 
> > resource's URI. A server SHOULD provide a Content-Location for the 
> > variant corresponding to the response entity; especially in 
> the case 
> > where a resource has multiple entities associated with it, 
> and those 
> > entities actually have separate locations by which they might be 
> > individually accessed, the server SHOULD provide a Content-Location 
> > for the particular variant which is returned.
> This is where things get fairly muddy. Variant is currently 
> defined as a kind of representation, but here all of the 
> sudden it's treated as a resource and given a URI. The first 
> instance could probably be replaced by just 'resource', or 
> just drop 'for the variant' entirely; in the second, 
> 'representation' would probably suffice.

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

- Brian
Received on Thursday, 31 January 2008 01:54:48 UTC

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