Re: Extension HTTP methods

That's not my recollection of where the WG ended up at the F2F; I was  
under the impression that someone was going to explain what the  
security issues are, exactly.

I did have an AI to list HTTP methods, but Julian has done it for me ;)
   http://greenbytes.de/tech/webdav/common-index.html#rfc.index.M


On 2006/05/14, at 12:04 PM, Anne van Kesteren wrote:

>
> On Sat, 15 Apr 2006 12:31:43 +0200, Pete Kirkham  
> <mach.elf@gmail.com> wrote:
>> I have worked with XMLHttpRequest (and also the Java http libraries)
>> and found it annoying that only a few of the WebDav and DeltaV  
>> methods
>> are supported. Often I've had to hack it with a server script to
>> tunnel the requests so that I end up with POST
>> http://example.com/my-stuff?method=MKACTIVITY rather than MKACTIVITIY
>> http://example.com/my-stuff so that I can use a repository from a
>> browser based application.
>>
>> Assuming that generic methods are supported by whitelists or some
>> other XSS protection, is there a reason why there needs to be a
>> restriction on the available methods? POST is often used for
>> destructive or billing operations, and a sensible restriction on the
>> method name (say 32 character limit of <any CHAR except CTLs or
>> separators> to prevent overrun attacks) rather than a restrive list.
>
> Currently some browsers have a whitelist and others have a  
> blacklist and the group has resolved to go for a whitelist  
> containing all safe methods that currently exist, unless the IETF  
> comes up with good reasons not to. There are currently some methods  
> that can't be allowed for security reasons and because such method  
> smay be introduced in the future as well allowing arbitrary method  
> names does not seem like a good idea.
>
>
> -- 
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>
>
>

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Monday, 22 May 2006 10:39:12 UTC