Re: Content-Location in Requests

     1. tor 2006-12-14 klockan 12:37 -0800 skrev Travis Snoozy (Volt):
> Section 14.14 (page 120) specifies behavior only for when
> Content-Location is included in a Response.

No, it defines Content-Location relative to entity and request-URI,
which is neutral (both request/response).

Then goes into details what this means for responses and how servers
should behave as this is the area where the RFC defines an actual use of
Content-Location.

> However, the final paragraph of that section states that "[t]he
> meaning of the Content-Location header in PUT or POST requests is
> undefined; servers are free to ignore it in these cases." This implies
> that, when Content-Location is present in a Request with a method
> other than PUT or POST, the server needs to handle the header in some
> fashion. This implied handling does not appear to be specified
> anywhere in the RFC, and some sections (such as 13.10, page 98)
> further add to the ambiguity.

My reading of the RFC ends up in a slightly different view:

Content-Location is an entity header. Only PUT or POST has a defined
meaning of request entities. For all other methods defined in RFC2616
the server SHOULD ignore any enclosed request entity. Exceptions to this
is that it's an MAY ignore in case of OPTIONS, and TRACE being special
echoing it but otherwise completely ignoring the request entity.

Only PUT defines clearly what servers should do with received entity
headers, and it's mainly this part the Content-Location exception for
PUT or POST is escaping from I guess.

Note: While it's true that the specs only clearly says that the request
message-body should be ignored unless specified for the method (4.3), it
makes more sense reading it as the whole request-entity should be
ignored as you can not have one without the other in a sane manner
(except for HEAD responses). This also is fully in line with the
requirement that unknown headers is to be processed as entity headers
and should be ignored by the recipient.

> My guess is that Content-Location, when present in a Request, tells
> the server the URI of the enclosed entity, with the side-effect of
> providing the base URI for the server to resolve relative URIs
> (presumably within the entity) against.

Yes.. that's defined the first paragraph of 14.14.

> But why would this not be the case for PUT or POST?

I would guess because the server side processing of PUT content isn't at
all specified by the RFC, and the reason why this paragraph exists is to
escape from the entity-headers storage requirement in PUT request. The
RFC pretty much assumes servers store PUT entities exactly as received,
and under such use case there is no meaning of Content-Location in the
request entity.

And to eliminate any confusion about what the URI of the crated resource
should be in PUT. 

It's also worth noticing that the RFC does not say servers SHOULD ignore
Content-Location, it only says server in the view of RFC2616 have no
obligation to care for the Content-Location header in PUT/POST requests.
It MAY if it feels it would be a good idea, but is not required to do so
by RFC2616.


Regards
Henrik