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, 31 Jan 2008 05:07:27 -0800
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <005e01c8640a$3b9f5f10$0501a8c0@T60>

Yves Lafon wrote:
> On Wed, 30 Jan 2008, Brian Smith wrote:
> > Mark Nottingham wrote:
> >> 10.2.2 (201 Created):
> > 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.

What about part 2, section 8.4 (HEAD):
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-01.t
xt

"If the new field values indicate that the cached entity differs from
the current entity (as would be indicated by a change in Content-Length,
Content-MD5, ETag or Last-Modified". Content-Length, Content-MD5, and
Last-Modified are all entity headers. 

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

If Content-Location = Location (as in RFC 5023), or if "201 Created"
really implies the creation of only one resource, then the meaning of
ETag is totally clear. However, Content-Location = Location will only be
the case when a resource is self-describing (contains a hyperlink to
itself).

I can see that the language that describes 9.2.2 uses singular language
("a new resource"), but if the intention is that exactly one new
resource is created, then I think it should be more explicit. If only
one resource is allowed to be created, then doesn't RFC 5023 effectively
require AtomPub servers to be non-compliant with RFC 2616? And, does
this restriction to one resource being created also imply that, when
Content-Location <> Location, the entity linked to by Content-Location
is a variant of the resource linked to in the Location (which would
again cause problems with RFC 5023 and probably others)?

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

- Brian
Received on Thursday, 31 January 2008 13:07:41 GMT

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