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

[Gabriel Montenegro <[e-mail]>]

Hi Julian,

Sorry for the delay. You say you're "not convinced". Perhaps I can't convince you as ultimately it might be a matter of taste. I can try to explain why my distaste for OPTIONS.

The issue with OPTIONS is that it is different in nature than GET. In both cases there is processing that must deal with existing code paths and usage. However, OPTIONS is meant for querying capabilities of the server. These capabilities are ever expanding by adding modules to your server. OPTIONS processing is typically farmed out to those modules since they are the only ones authoritative about the capabilities available via that particular module. So there's significant OPTIONS processing not just at the server, but at random modules that happen to be added at that server (which may happen even in the presence of a path).  Mixing in what random modules will do as part of their processing and how that might or might not affect OPTIONS processing, and in what mix of random modules, etc,  is too much randomization into the Upgrade processing. It's also the method to use to find out if the server supports websockets, except it is being proposed also as the method to use to actually invoke them. It would be best from simplicity point of view to keep  those two roles separate. 

We've been taking into consideration the enormous variability of infrastructure and proxies in our decisions so far, I think ignoring the ever expanding processing of OPTIONS due to random modules or plug-ins at servers, and how that will interact with websockets is inconsistent with that concern.

That's why I think it is the worst of all methods being discussed.

Gabriel

> -----Original Message-----
> From: Julian Reschke [mailto:[e-mail]]
> Sent: Saturday, January 29, 2011 1:04 AM
> To: Gabriel Montenegro
> Cc: Salvatore Loreto; [e-mail]; Joe Hildebrand; SM
> Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method
> 
> 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_(OWA
> SP-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