Subject: Content-Location in Requests

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Thu, 14 Dec 2006 12:37:18 -0800

Section 14.14 (page 120) specifies behavior only for when Content-Location is included in a Response. 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 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. But why would this not be the case for PUT or POST?

Does anyone have any clarification as to what the intent of section 14.14 is?

Thanks,

-- Travis

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 15 Dec 2006 01:57:33 +0100

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

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Mon, 18 Dec 2006 10:01:53 -0800

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

> 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

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 19 Dec 2006 01:24:03 +0100

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

My by "request entity" (no -) i mean "the entity enclosed in the
request".

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

The definition in 1.3 of "entity" is pretty clear on this.. so all uses
of entity which refers to specifically a request or response should
indicate so. All other uses should be assumed to be on an HTTP message
in general, not specifically a request or response.  If there is uses of
"entity" which only makes sense in one of request or response context
but it isn't specified directly or indirectly by the surrounding context
this should be fixed.

Regards
Henrik