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

Lisa Dusseault wrote:
> 
> 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.   

Well, we already discussed it. Turns out it's underspecified, not 
implemented in Apache or IIS, and Roy said it needs to be fixed 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0095.html>).

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

The requirement has been there for over 10 years, and clients still 
can't rely on it (at least if they use the two most widely deployed 
servers allowing PUT). This should tell us something, I guess.

> 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-implement-otherwise-fail.  

Although I link many things in RFC2774, I'll have to point out it's not 
widely implemented either. We probably will have to live with Must-Ignore.

Now, for PATCH things *could* be defined otherwise. To do that, I'd like 
to have a clarification of what it means to "understand or implement" a 
Content-* header in the context of PATCH (*), and also a use case that 
needs this. Otherwise it'll be a useless deviation from other HTTP 
methods, and will get as much implementation as it got for PUT.

Best regards, Julian

(*) So, what does "Content-Range" mean for PATCH?

Received on Tuesday, 31 July 2007 16:10:08 UTC