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

Re: Extension HTTP methods

From: Gorm Haug Eriksen <gormer@opera.com>
Date: Mon, 15 May 2006 00:36:54 -0700
To: "Julian Reschke" <julian.reschke@gmx.de>, "Anne van Kesteren" <annevk@opera.com>
Cc: "Jim Ley" <jim@jibbering.com>, "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s9k0rspqm2jbu9@pt-osx.oslo.opera.com>

On Sun, 14 May 2006 23:48:46 -0700, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> Anne van Kesteren wrote:
>>  I'm just stating the resolutions as they have been made here. Feedback  
>> from implementors suggested that TRACE and CONNECT have issues and that  
>> future HTTP methods might become problematic (new specification  
>> released, servers updated, UAs are not, hole). What was raised against
>
> What kind of issues? Please be more specific.

Hi Julian,

I don't think these two methods are allowed in any implementations today  
so they shouldn't be in use. However, the biggest concern is that someone  
has implemented a HOBBIT method that do something insecure. I have spoken  
with some security people and they are concerned although we in the group  
see benefits in having arbitrary verbs.

> Furthermore: if specifications update the definitions of methods in an  
> incompatible way, that's first of all the problem of these  
> specifications. The whole point in publishing specifications about new  
> HTTP methods is *not* to change them in incompatible ways once they are  
> deployed. If a standards body fails to adhere to that rule - their  
> problem.

I guess the problem is the vendors here. The specification will try to  
minimize the problems with already deployed solutions, but I think a  
couple of vendors was a bit quick. E.g. if you try IE7 today you will see  
that they have changed their behaviour. FF probably followed IE6 and  
allowed arbitrary verbs. Opera has never allowed it.

> Don't cripple XHR because of that.

I don't think it will be to much crippled. It would still be possible to  
use headers to signal. I think the specification should provide a method  
on a method that would satisfy the use-case of inventing new verbs. E.g. a  
namespace on verbs or a custom header to signal the verbs.

> In my opinion, forbidding implementations to allow arbitrary HTTP  
> methods is clearly the wrong thing to do.

I don't think the idea is to forbid, but rather have a white-list that we  
all can agree on supporting. This list should contain all the verbs widely  
in use today.

> (Speaking as active member of the IETF WebDAV working group, and as  
> author or co-author of several WebDAV related RFCs - most of which  
> defining new HTTP methods)

The WebDAV methods will probably be on top of that list :) Also, the  
current suggestion is only a suggestion that will need more public  
comments and work. Hope this email clarify some of your concerns and  
explains a little on the reasons behind this issue. Thanks!

Cheers,

- Gorm Haug Eriksen
Received on Monday, 15 May 2006 07:37:00 GMT

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