RE: Content-Location in Requests

2006-12-14 16:58 -0800 Henrik Nordstrom wrote:
<snip>

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

<snip>

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

Thanks!

-- Travis

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