Re: Extension HTTP methods

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.

> 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?

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?

> 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?

>> 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.

>> 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.

Again, this restricts what future specs can do then.

>> (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!

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?

Best regards, Julian

Received on Monday, 15 May 2006 10:21:16 UTC