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

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 May 2009 16:15:51 +1000

So, to summarise, it seems like we have agreement here that removing   
"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."

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

On 31/07/2008, at 11:36 PM, 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.
>
> Regards,
> Brian
>

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 May 2009 08:49:34 +0200

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/79> goes...

Agreed.

Proposed patch in 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/80/80.diff>.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 06 May 2009 10:41:19 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 May 2009 10:50:50 +0200

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/80/80.diff>.

Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/577>.

BR, Julian