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

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