Re: Extension HTTP methods

+1

On 2006/06/08, at 6:34 AM, Julian Reschke wrote:

> Charles McCathieNevile schrieb:
>> POST could be used to do so, but there is nothing in its defined  
>> semantics that forces it to be used like that. POST hands the body  
>> to something and says "do with this as you see fit", PUT says  
>> "begone, this is your replacement".
>
> Well. A server may replace a resource based upon POST. Another  
> server may reject PUT with 501.
>
> The client doesn't know in advance. Nor do the authors of this  
> specification.
>
>>>>>> We can provide a list of verbs that MUST be supported, and say  
>>>>>> that implementations should allow other verbs, but note for  
>>>>>> authors thatimplementations may not, for example due to  
>>>>>> security concerns.
>>> Well, that's the point I violently disagree with. By disallowing  
>>> "unknown" methods, this spec would be profiling HTTP and thus  
>>> restricting what other standards bodies can do. As far as I am  
>>> concerned, this is something this WG clearly shouldn't do.
>> Ah. We are violently agreeing. By saying that certain methods MUST  
>> be supported, and others SHOULD (but MAY NOT) all methods are  
>> legal, although authors are warned that relying on new methods  
>> working in all systems is not necessarily the smartest thing to do  
>> - they should know whether the system supports their method.
>
> That's fine with me. Thus, we need the "SHOULD" for the methods not  
> listed as "MUST", and it should also be discussed when it's  
> appropriate not to support a specific method.
>
> Finally, a user of the XHR MUST (!!!) be able to detect that an XHR  
> implementation indeed did not support a method (thus silent mapping  
> to GET is a severe bug!).
>
>>> So what would be the recommended spec text then (yes, I know, I'm  
>>> supposed to make a proposal myself...).
>> Suggestion:
>> Implementations MUST support the methods GET, PUT, POST, DELETE,  
>> HEAD, FooBar, Barfoo, BuyMeABeer, etc. Other methods SHOULD be  
>> supported, allowing headers and a body to be sent and received.  
>> Authors are advised that for security or other reasons, some  
>> implementations MAY NOT support methods beyond those given in the  
>> list above.
>
> Nit: "MAY NOT" isn't an RFC2119 keyword. Essentially MAY and MAY  
> not mean the same thing :-)
>
>> (The list of must-support methods is up for argument, I suppose,  
>> although I believe we can (and am sure we should) get consensus on  
>> it relatively fast).
>
> Minimally, it should include all methods defined in IETF standards  
> tracks documents.
>
> Best regards, Julian
>
>

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Thursday, 8 June 2006 16:14:27 UTC