Re: Extension HTTP methods

On Thu, 08 Jun 2006 21:50:30 +1000, Julian Reschke <julian.reschke@gmx.de>  
wrote:

>
> Charles McCathieNevile schrieb:

> How is PUT more dangerous than POST, if a POST can overwrite an existing  
> resource as well?

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

> In particular, if "dangerous" methods aren't available through XHR,  
> server implementors may be encouraged to add alternative POST interfaces  
> for these "dangerous" actions (such as in SOAP), so nothing is won in  
> the end...

agreed.

>>  Hmm. IESG review doesn't prove something isn't a security risk - but  
>> nor does the WebAPI or some implementor's say-so prove that it is.
>
> But at least it's an indicator (meaning that somebody actually *has*  
> done a security review :-).

That's not necessarily a good thing :-) False senses of security are the  
bread and butter of phishing... but we digress.

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

...
> Well, of the shipping UAs Firefox and IE 6.x support all methods, while  
> Safari and Opera are clearly buggy (they silently replace unknown  
> methods by GET; if they reject certain methods, they should do that  
> explicitly by throwing an exception, not by silently doing something  
> else).

Sure, but this is a seperate issue.

>> extend HTTP is probably a good reason to allow extended methods, so we  
>> don't have to change the spec or go tell foo.org that their new work is  
>> incompatible with our spec until we make another revision.
>
> 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.

(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).

Cheers

Chaals

-- 
Charles McCathieNevile                     chaals@opera.com
   hablo español  -  je parle français  -  jeg lærer norsk
      Peek into the kitchen: http://snapshot.opera.com/

Received on Thursday, 8 June 2006 13:24:42 UTC