- From: Brian Smith <brian@briansmith.org>
- Date: Thu, 31 Jan 2008 05:07:27 -0800
- To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
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 UTC