W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

RE: Content-Location in Requests

From: Travis Snoozy (Volt) <a-travis@microsoft.com>
Date: Mon, 18 Dec 2006 10:01:53 -0800
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <86EDC3963F04D546BED8996F77D290F6049C895EEF@NA-EXMSG-C138.redmond.corp.microsoft.com>

2006-12-14 16:58 -0800 Henrik Nordstrom wrote:

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


[ed: There's no "request-entity" defined in the spec; I assume the meaning here is "the whole entity" (which just happens to be in a Request, for our purposes).]

I agree with your analysis here; I didn't think to look back to section 4.3. So, the spec is just a bit awkward to understand and a little vague. A cross-reference from section 14 to section 4.3 or section 7 might be helpful, as well as being more explicit about servers ignoring entire entities (as opposed to just message-bodies).

In any case, you've cleared up my confusion on this point.


-- Travis
Received on Monday, 18 December 2006 18:02:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:47:10 UTC