W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: Content-* Semantics [i103][i102]

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 29 Feb 2008 10:22:31 +1100
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <56FCAF66-C3EA-484A-9284-05D3DDBB34DA@mnot.net>
To: Brian Smith <brian@briansmith.org>

That's a pretty big change, considering the previous text;
> The recipient of the entity MUST NOT ignore any Content-* (e.g.  
> Content-Range) headers that it does not understand or implement and  
> MUST return a 501 (Not Implemented) response in such cases.
Doing away with this would likely cause problems for existing  
implementations (and WebDAV?).

For non-PUT methods, the default is already to ignore the headers you  
don't understand. Regurgitation for the case of POST is an application- 
specific thing, and I'm not sure what the spec can really say about  
that; it's more implementation advice than HTTP spec language.

Other methods that may have "regurgitation" implications -- e.g.,  
PATCH -- will have to craft their own language like POST's.

So, I'm -1 on i102 (which is what this discussion is really about).

On 29/02/2008, at 12:07 AM, Brian Smith wrote:

> Perhaps the
> requirement should be written as "Clients and origin servers SHOULD
> ignore headers they don't understand and SHOULD NOT send headers they
> don't understand (do not 'regurgitate' anything)", and moved to some
> place that describes how headers should be processed generally. This
> requirement is definitely not specific to PUT, considering that it  
> often
> applies to POST (whenever it is used as "PUT at server-assigned
> location"), and will probably apply to PATCH too. And, it applies to
> clients as well as servers; a client shouldn't send a header it  
> receives
> from a server unless it understands that header.

Mark Nottingham     http://www.mnot.net/
Received on Thursday, 28 February 2008 23:23:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC