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

Re: Extension HTTP methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 15 May 2006 19:08:29 +0200
Message-ID: <4468B58D.9050207@gmx.de>
To: Gorm Haug Eriksen <gormer@opera.com>
CC: Anne van Kesteren <annevk@opera.com>, Jim Ley <jim@jibbering.com>, "Web APIs WG (public)" <public-webapi@w3.org>

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
Received on Monday, 15 May 2006 17:11:22 UTC

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