Re: Extension HTTP methods

Gorm Haug Eriksen wrote:
> ...
>> 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'm not following. If I need a specific method name, and XHR doesn't 
allow me to use it, I'm stuck, right?

>> 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, it's not crippled in IE6 and Firefox, which are the most widely 
used UAs today.

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

I think both approaches would be bad.

Best regards, Julian