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

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

Received on Tuesday, 29 July 2008 19:29:50 UTC