W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: Comments on draft-dusseault-http-patch-08, was: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 31 Jul 2007 08:54:43 -0700
Message-Id: <B0D8C004-0D30-4DD0-9181-18515788F351@osafoundation.org>
Cc: jasnell@us.ibm.com, ietf-http-wg@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

On Jul 25, 2007, at 1:55 AM, Julian Reschke wrote:

>     The server 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.
> A MUST level requirement with a wild card Just Does Not Work.  I'm  
> not even sure what this is about.  As far as I understand what we  
> could say, if at all, is that entity headers sent with the request  
> apply to the enclosed entity, not the resource being addressed.   
> Thus, for instance, a "Content-Language" request header in PATCH  
> describes the natural language of the patch document (entity).  So  
> what why would it be a problem to ignore it?  Or, rephrasing it,  
> what do you expect the server to do with it?

This is the same requirement found in RFC2616 for PUT, and for the  
same reasons.

It's easy to implement.    If the server receives a header beginning  
with "Content-" that is not in some list of "Content-" headers it has  
code to deal with in a request, like "Content-Range" or "Content- 
Signature", then it needs to return 501 Not Implemented.   It would  
be a problem to ignore these headers because the client means  
something about the request body which won't be handled if they're  

It's a standard type of requirement to allow future extensions to be  
designed more flexibly.  A more generic approach can be found in  
RFC2774 where "mandatory" header prefixes indicate mandatory-to- 

Received on Tuesday, 31 July 2007 15:55:04 UTC

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