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

On 7/29/08, Brian Smith <brian@briansmith.org> wrote:
> Mark Baker wrote:
>  > On Tue, Jul 29, 2008 at 2:02 PM, Julian Reschke
>  > <julian.reschke@gmx.de> 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.

Received on Tuesday, 29 July 2008 20:20:40 UTC