Re: Extension HTTP methods

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

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

Cheers,

- Gorm Haug Eriksen

Received on Monday, 15 May 2006 11:56:20 UTC