W3C home > Mailing lists > Public > public-webapi@w3.org > June 2006

Re: Extension HTTP methods

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 8 Jun 2006 09:03:38 -0700
Message-Id: <B5D9EA19-38C9-4477-BA66-A1FC795B4F06@yahoo-inc.com>
Cc: Charles McCathieNevile <chaals@opera.com>, Ian Hickson <ian@hixie.ch>, "Web APIs WG (public)" <public-webapi@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>


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
Received on Thursday, 8 June 2006 16:14:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC