W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

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

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 06 May 2009 10:41:19 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Brian Smith <brian@briansmith.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Mark Baker'" <distobj@acm.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <1241599279.8939.165.camel@henriklaptop.lan>
ons 2009-05-06 klockan 16:15 +1000 skrev Mark Nottingham:
> "The meaning of the Content-Location header in requests is undefined;  
> servers are free to ignore it in those cases."
> 
> It seems like there may be a bit of alignment needed, depending on how  
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/79> goes...

I consider the two pretty much separate. 

Servers are always free to ignore Content-* headers they understand, and
Content-Location is generally no problem if ignored as there is no
defined meaning of Content-Location in a PUT. (also it semantically
conflicts somewhat with the PUT URI).

But I do seriously doubt that anyone implements the Content-*
requirements in PUT processing when seeing headers they don't understand
or know about...

Because of this I propose that 79 is resolved by downgrading these to
SHOULD level (both of them). It's a good rule, and makes sense when
implemented, but as many don't clients cant really rely on servers
implementing it, but may still have it as a requirement for using the
client.

But I don't expect this to have much of a significant effect on actual
use of PUT. In most uses there is some form of negotiation (mostly
out-of-band in file extensions etc) on the URL to PUT to for storing
content with special Content-* requirements, defining the stored
Content-* properties by URL rather than PUT headers..

Regards
Henrik
Received on Wednesday, 6 May 2009 08:42:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:02 GMT