Re: [hybi] straw-poll on GET vs OPTIONS vs new method

[Julian Reschke <[e-mail]>]

On 29.01.2011 08:03, Gabriel Montenegro wrote:
> ...
> The point that previous uses of OPTIONS can lead to confusion with previous usage was made in reference to its use in CORS (http://www.w3.org/TR/cors/). There's also WEBDAV (http://tools.ietf.org/html/rfc4918) and others.  This point argues for WEBSOCKET (a brand new method with no other previous usage) over either GET or OPTIONS.
> ...

I don't think there's a problem with OPTIONS and WebDAV. WebDAV uses 
OPTIONS just the way it's designed for, and I'm not aware of any 
potential problems using OPTIONS in other protocol exchanges as well. If 
you do, you need to elaborate.

OPTIONS and CORS is a slightly different story because of the stupid 
requirement CORS makes on OPTIONS not to require authentication. That's 
a design flaw in CORS. I'm not sure how it would affect usage of OPTIONS 
over here, though.

> +1 WEBSOCKET
>
> Even though both GET and OPTIONS have existing usage, they are not equally safe. GET and POST (which are by far the most used) undergo much more scrutiny than other lesser-known or completely arbitrary methods. Lesser methods can be used to exploit vulnerabilities in faulty ACL checking:
> http://www.owasp.org/index.php/Testing_for_HTTP_Methods_and_XST_(OWASP-CM-008)#Arbitrary_HTTP_Methods

Not convinced. The linked text correctly reports that some frameworks do 
only ACL on certain methods, but then fallback to execute unknown 
methods as GET. That's a bug, indeed. Do we have evidence that 
Websockets is going to be deployable on frameworks like these anyway? 
Also, these frameworks are vulnerable already, how does Websockets 
change the situation?

 > ...
> Another point against GET and OPTIONS is that both are supposed to be idempotent. This has been misconstrued as a requirement to cause no changes at the server. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-7.1.2 clarifies:
>
>     ...  It is important to
>     note that idempotence refers only to changes requested by the client:
>     a server is free to change its state due to multiple requests for the
>     purpose of tracking those requests, versioning of results, etc.
>
> Since the Upgrade effects a change on the connection, not on the resource, I don't see idempotence as an argument against GET, OPTIONS or any other idempotent method.
> ...

That's correct.

Best regards, Julian