- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 15 May 2006 19:08:29 +0200
- 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