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

On Jul 31, 2007, at 9:09 AM, Julian Reschke wrote:

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

I can certainly deal with something along these lines.  I agree this  
kind of thing is poorly implemented and appreciate the testing.  If  
2616 changes we could also change PATCH if the timing is right.

When should we attempt to have a HTTP Interop event?  A test suite  
like LITMUS (in fact I think part of Litmus can be reused) would go a  
long way towards alerting implementors to simple requirements that  
are easily missed.  A test suite could attempt a PUT with "Content- 
BOGUS: MUST FAIL" (assuming we kept this requirement) and expect to  
see at least some kind of error if not a 501.

Lisa

Received on Tuesday, 31 July 2007 16:46:36 UTC