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
