On Wed, 07 Jun 2006 23:46:09 +0200, Mark Nottingham <[EMAIL PROTECTED]> wrote:
Blindly standardising what one vendor does doesn't make sense;
We can certainly assume they have thought long and hard about a change that WILL break existing content.
do you know *why* they consider it a security feature?
I have heard the verb "CONNECT" brought up as an especially important one that scripts should not be allowed to send at random due to its usage to initiate HTTPS connections. I don't know enough about SSL to discuss abuse scenarios.
The reputed security problems with various HTTP methods have been brought up many times, but I have yet to see an explanation of how they actually cause a security issue greater than supporting POST does.
If you look at the "request smuggling" [1] exploits there is plenty of scope for problems even in the naive implementations of HTTP GET/POST. If you can send a random verb you could probably "fake" a protocol with other conventions for how content is sent, thereby making it harder to secure proxies and servers against request smuggling.
I assume allowing random verbs for XHR will make it harder to develop HTTP or HTTP-compatible protocols in the future because Joe Web Developer will have used verbs in a random web app that might clash with a particular development of HTTP, and noone will find out until the server is upgraded to support the new HTTP version and the web app falls apart... Even though I don't know the security aspect in depth I can agree that extending HTTP with new verbs is up to some comittee in IETF or W3C, not something any random web developer should be doing because they can.
[1] http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf -- Hallvord R. M. Steen Core QA JavaScript tester, Opera Software http://www.opera.com/ Opera - simply the best Internet experience
