Re: Extension HTTP methods

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

Received on Thursday, 8 June 2006 13:41:36 UTC