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

Re: Extension HTTP methods

From: Hallvord R. M. Steen <hallvord@opera.com>
Date: Mon, 12 Jun 2006 11:42:22 +0200
To: "Hallvord R. M. Steen" <hallvord@opera.com>, "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "Mark Baker" <distobj@acm.org>, "Anne van Kesteren" <annevk@opera.com>, "Pete Kirkham" <mach.elf@gmail.com>, "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.ta008wkpa3v5gv@id-c0418.upc.no>

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.


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.

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.


-----Original Message-----
From: Hallvord R. M. Steen
Sent: Friday, June 09, 2006 4:30 AM
Subject: the W3C web-api group discussing HTTP verbs

I know you've discussed the security implications of allowing JavaScripts
to use arbitrary HTTP verbs with XMLHttpRequest. This very issue is being
discussed on the public-webapi mailing list regarding the XMLHttpRequest
specification.

Most people on the list seem to be in favour of allowing arbitrary verbs
(perhaps not surprising given that mostly client-side developers are
represented) and the question that comes up is what exactly the security
risks are. I know you think there are some, but I don't have a full
understanding myself.

Perhaps either of you could explain some of the risks or join in the
discussion?

If you want to see the discussion look for the "Extension HTTP methods"
thread here:
http://lists.w3.org/Archives/Public/public-webapi/2006May/thread.html
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/thread.html

Thanks for any input!


-- 
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience
Received on Monday, 12 June 2006 09:40:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT