Re: Extension HTTP methods

Hallvord R. M. Steen schrieb:
> On Fri, 09 Jun 2006 13:21:00 +0200, Hallvord R. M. Steen 
> <hallvord@opera.com> wrote:
> 
>>>>> Blindly standardising what one vendor does doesn't make sense;
>>>>  We can certainly assume they have thought long and hard about a 
>>>> change that WILL break existing content.
>>>
>>> It would be really great if we could work based on facts instead of 
>>> hearsay.
>>
>> Yes, but I can't quote people verbatim on a public mailing list 
>> without their permission.
>> I will ask the MS developer and our senior HTTPS/networking dev if 
>> they can give me an explanation I can pass on, or even respond in this 
>> thread.

Thanks for finding out...

> Here is the response:
> 
> 
> The problem is that there's no way we can guarantee correct behavior for 
> new HTTP verbs whose semantics are not yet defined.  For instance, 
> should a given method be idempotent?  Are its results eligible to be 
> cached?  Etc.

If the method is unknown, you don't know. Make it configurable or choose 
a safe default (that is, response not cacheable, method not safe, method 
not idempotent).

The current IE7 implementation rejects REPORT. This method is safe as 
per a 4 year old standards track RFC. So I'll assume that is a bug in IE7?

> One of the security issues from allowing arbitrary verbs was reported a 
> few years ago.  The "TRACE" verb can be used to circumvent the HTTPONLY 
> cookie directive.  
> http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf.  While 
> the threat was overhyped (and can be fixed by disabling TRACE on the 
> server) the concern about permitting verbs with unknown 
> side-effects/combinatorial-effects remains.

How would an unknown method by more dangerous than POST?

Best regards, Julian

Received on Monday, 12 June 2006 09:51:41 UTC