Subject: Issue 80, was: NEW ISSUE: Content-Location vs PUT/POST

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Jul 2008 19:02:37 +0200

Mark Nottingham wrote:
> 
> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80
> 
> 
> On 01/08/2007, at 2:17 AM, Julian Reschke wrote:
> 
>> the definition of Content-Location 
>> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.14.p.7>) 
>> ends with:
>>
>> "The meaning of the Content-Location header in PUT or POST requests is 
>> undefined; servers are free to ignore it in those cases."
>>
>> This was added in RFC2616 (does not appear in RFC2068).
>>
>> I have no problem allowing servers to ignore it. However:
>>
>> 1) It seems that the meaning of Content-Location is universal for 
>> messages that carry an entity; I'm not sure what's the point in 
>> claiming that meaning does not apply to PUT or POST.
>>
>> 2) Also: every time a limited set of methods is mentioned somewhere it 
>> feels like problematic spec writing. What makes PUT or POST so special 
>> in comparison to other methods? Maybe that they are the only methods 
>> in RFC2616 that carry request entity bodies? In which case the 
>> statement should be rephrased accordingly...
>  ...

Proposal: just drop "PUT and POST" from the sentence, making it:

"The meaning of the Content-Location header in requests is
undefined; servers are free to ignore it in those cases."

BR, Julian

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 29 Jul 2008 13:16:15 -0400

>  undefined; servers are free to ignore it in those cases."

Eek, no, that seems to head in the opposite direction, as its meaning
is perfectly clear AFAICT.  I say we just remove the whole sentence.

Mark.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Jul 2008 19:21:41 +0200

> is perfectly clear AFAICT.  I say we just remove the whole sentence.

I see.

How about saying just:

   "The meaning of the Content-Location header in requests is undefined."

Because otherwise we'll get people asking where it's defined :-)

BR, Julian

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 29 Jul 2008 13:51:10 -0400

>  Because otherwise we'll get people asking where it's defined :-)

8-)  But it's an entity header, so it means the same thing in requests
and responses.

Mark.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Jul 2008 20:02:35 +0200

> 8-)  But it's an entity header, so it means the same thing in requests

So, for instance for PUT, servers are expected to store it and return 
them in a subsequent GET?

BR, Julian

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 29 Jul 2008 14:35:37 -0400

On Tue, Jul 29, 2008 at 2:02 PM, Julian Reschke <[email-masked]> wrote:
> So, for instance for PUT, servers are expected to store it and return them
> in a subsequent GET?

That's up to the server.  From an HTTP POV, the meaning of both
request and response messages containing a Content-Location header
seems unambiguous.

FWIW though, after just re-reading the section, the definition does
seem to read like that of a response header, in particular the whole
"The Content-Location value is not a replacement for the original
requested URI" paragraph.  To clear that up, I propose changing that
to "In response messages, the Content-Location value is not [...]".
This is in addition to removing the aforementioned "PUT or POST"
sentence at the end.

Mark.

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Jul 2008 14:29:15 -0500

Mark Baker wrote:
> > So, for instance for PUT, servers are expected to store it 
> > and return them in a subsequent GET?
> 
> That's up to the server.  From an HTTP POV, the meaning of 
> both request and response messages containing a 
> Content-Location header seems unambiguous.

It causes problems because Content-Location determines the base URI for
relative URI references in a response. If it means anything in a *request*
then I expect it would retain this base-URI functionality there too. But, a
server cannot echo the Content-Location as the client sent it (because it
may be a URI on a totally unrelated server), and it can't be expected to
find and rewrite all the URI references in the request entity before
republishing it. Saying that Content-Location is undefined in requests is
important because that statement indicates to client software authors that
they cannot rely on using this header as the base URI when submitting
documents to servers; they need to use xml:base or similar mechanisms.

- Brian

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 29 Jul 2008 16:20:00 -0400

On 7/29/08, Brian Smith <[email-masked]> wrote:
>  republishing it.

Good point.  More important than what servers can be expected to do
though, I doubt there's many/any that do this today.  There's not even
an upgrade path where that functionality can be incrementally
deployed, as HTTP doesn't have the mandatory extension mechanism that
would be required to prevent existing servers from misinterpreting
requests using Content-Location.

> Saying that Content-Location is undefined in requests is

Thanks, I'm convinced.

In that case, I'm for Julian's proposal to simply remove "PUT or POST"
in the last paragraph.

Mark.

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 31 Jul 2008 05:10:17 +0200

> In that case, I'm for Julian's proposal to simply remove "PUT or POST"

+1 on the first of those, where the server is still given persmission to
ignore Content-Location in requests, but not on the second where this
was removed.

In the definition of PUT there is the following restriction which
otherwise relates to Content-Location:

  "The recipient of the entity MUST NOT ignore any Content-* (e.g.
   Content-Range) headers that it does not understand or implement
   and MUST return a 501 (Not Implemented) response in such cases."

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Jul 2008 15:28:31 +0200

>    and MUST return a 501 (Not Implemented) response in such cases."

That's a good one, isn't it?

I read it as:

- find all content-* headers

- for those understood, either ignore them or process them

- if some are not understood, reject the request

Which means: it's ok to ignore Content-Location, if you "know" it.

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 31 Jul 2008 08:36:25 -0500

> Which means: it's ok to ignore Content-Location, if you "know" it.

I agree. Put another way, it is okay to remove or replace a Content-* header
but you cannot ignore ones you don't understand. 

Regards,
Brian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 31 Jul 2008 21:37:22 +0200

> but you cannot ignore ones you don't understand.

And the reasons behind this is pretty simple. If you do not know what a
Content-* header means it's very likely you also do not know how to
handle the enclosed entity body in a sensible manner meaningful in PUT
context. Consider for example Content-Encoding where not understanding
the header and blindly ignoring it without considering the consequenses
will have quite dramatic effects on the end result. Similarly for most
other defined Content-* headers. (note: sniffing/guessing put aside
here..)

But in the end, how a server stores a resouce is an implementation
detail. Specs only care that the server can understand what it is
requested to store.

Regards
Henrik