NEW ISSUE: Content-Location vs PUT/POST

[Julian Reschke]

Hi,

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

Best regards, Julian

[Henrik Nordstrom-5]

On tis, 2007-07-31 at 18:17 +0200, Julian Reschke wrote:

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

Not sure.

Personally I would rather see PUT be allowed to reject messages with an
mismatch in Content-Location. The result of such operation is not likely
to be what was intended..

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

Probably.

Suggestion:

Drop "PUT or POST " from that sentence, making it apply in general to
any kind of request. Which I guess is also what all servers do...


Regards
Henrik

[Julian Reschke]

Henrik Nordstrom wrote:

> On tis, 2007-07-31 at 18:17 +0200, Julian Reschke wrote:
>
>> 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.
>
> Not sure.
>
> Personally I would rather see PUT be allowed to reject messages with an
> mismatch in Content-Location. The result of such operation is not likely
> to be what was intended..

Can you define "mismatch" here? When a client says "here's another
Content location for the entity I'm sending", how can the server dtect a
mismatch? (well, except for fetching the entity and comparing?)

>> 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...
>
> Probably.
>
> Suggestion:
>
> Drop "PUT or POST " from that sentence, making it apply in general to
> any kind of request. Which I guess is also what all servers do...

That would work for me.

Best regards, Julian

[Henrik Nordstrom-5]

On tis, 2007-07-31 at 20:48 +0200, Julian Reschke wrote:

> Can you define "mismatch" here? When a client says "here's another
> Content location for the entity I'm sending", how can the server dtect a
> mismatch? (well, except for fetching the entity and comparing?)

For a server doing raw PUT:

If Content-Location differs from the Request-URI, or different from the
intended store location when the Request-URI is a negotiated resource.


For a server processing the PUT entity and not storing the
Content-Location:

If the entity can not be processed in such manner that any references in
it makes sense at it's stored location, compared to the
Content-Location.


Regards
Henrik

[Mark Nottingham-2]

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

--
Mark Nottingham     http://www.mnot.net/

[Julian Reschke]

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

[distobj]

On 7/29/08, Julian Reschke <julian.reschke@...> wrote:
>  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."

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.

[Julian Reschke]

Mark Baker wrote:
> On 7/29/08, Julian Reschke <julian.reschke@...> wrote:
>>  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."
>
> 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.

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

[distobj]

On 7/29/08, Julian Reschke <julian.reschke@...> wrote:

> Mark Baker wrote:
>
> > On 7/29/08, Julian Reschke <julian.reschke@...> wrote:
> >
> > >  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."
> > >
> >
> > 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.
> >
>
>  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 :-)

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

Mark.

[Julian Reschke]

Mark Baker wrote:

> On 7/29/08, Julian Reschke <julian.reschke@...> wrote:
>> Mark Baker wrote:
>>
>>> On 7/29/08, Julian Reschke <julian.reschke@...> wrote:
>>>
>>>>  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."
>>>>
>>> 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.
>>>
>>  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 :-)
>
> 8-)  But it's an entity header, so it means the same thing in requests
> and responses.

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

BR, Julian

[distobj]

On Tue, Jul 29, 2008 at 2:02 PM, Julian Reschke <julian.reschke@...> 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.

[Brian Smith-19]

Mark Baker wrote:
> On Tue, Jul 29, 2008 at 2:02 PM, Julian Reschke
> <julian.reschke@...> 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

[distobj]

On 7/29/08, Brian Smith <brian@...> wrote:

> Mark Baker wrote:
>  > On Tue, Jul 29, 2008 at 2:02 PM, Julian Reschke
>  > <julian.reschke@...> 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.

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

Thanks, I'm convinced.

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

Mark.

[Henrik Nordstrom-5]

On tis, 2008-07-29 at 16:20 -0400, Mark Baker wrote:

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

+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

[Julian Reschke]

Henrik Nordstrom wrote:

> On tis, 2008-07-29 at 16:20 -0400, Mark Baker wrote:
>
>> In that case, I'm for Julian's proposal to simply remove "PUT or POST"
>> in the last paragraph.
>
> +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."

 > ...

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

[Brian Smith-19]

Julian Reschke wrote:
> 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

[Henrik Nordstrom-5]

On tor, 2008-07-31 at 08:36 -0500, Brian Smith wrote:
> Julian Reschke wrote:
> > 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.

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