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 04:56:09 -0700
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Anne van Kesteren" <annevk@opera.com>, "Jim Ley" <jim@jibbering.com>, "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s9lcrvb2m2jbu9@pt-osx.oslo.opera.com>

On Mon, 15 May 2006 03:18:32 -0700, Julian Reschke <julian.reschke@gmx.de>  

> Gorm Haug Eriksen wrote:
>>> 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
> If these are problematic, blacklist them.

They should indeed be mentioned and they are already blacklisted.

>> 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.
> How can an arbitrary verb be more dangerous than POST?

It depends on what they do. The security guys might know of verbs that  
kills...what do I know?

> Please consider that if arbitrary methods can not be used with XHR,  
> future specification may be forced to use POST instead. So by banning  
> methods you don't know, you will make it more likely that people use  
> POST in the future, which is the contrary of what you wanted to achieve  
> initially, right?

If you are talking about specification writers I agree. If you speak for  
applications developers, I think they could use a header for the verbs  
instead. A simple proxy that tunnels the verbs should also work.

>> 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.
> Do we have any evidence that IE7's current behavior is intentional? Did  
> anybody raise a bug report yet?

I have reason to believe their behaviour is intentional and because of  
security concerns, but I'm not totally sure. I know that the security  
people here at Opera are against this behaviour and I suspect that the  
Safari guys are also against this behaviour (since they do not support  
arbitrary verbs).

>>> 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.
> You would be crippling the ability of protocol designers to use new  
> methods, that is one well understood HTTP extension mechanism would be  
> closed.

But it's already crippled today and not agreed upon! If you make design  
based on the current behaviour you are making a big mistake.

> Well, would that white list contain MKREDIRECTREF, UPDATEREDIRECTREF,  
> BIND, UNBIND and REBIND today? Once browser ship with these white lists,  
> is there any update strategy?

Right. This concern is valid and should be addressed in the spec. However,  
I think that having this white-list is better than only GET, POST and PUT  
(which I believe might be an alternative).


- Gorm Haug Eriksen
Received on Monday, 15 May 2006 11:56:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC