Re: [hybi] OPTIONS (was Re: It's time to ship)

On 10.01.2011 02:17, Roy T. Fielding wrote:
> On Jan 9, 2011, at 4:56 PM, Julian Reschke wrote:
>> For simplicity, the best *server* side choice IMHO is to treat Upgrade the same way for a given URI, no matter what what request method was.
>
> No, the value of upgrade is similar to conditional GETs:
> asking for an optional improvement to the protocol without
> costing an extra round trip.  The common case is a normal
> GET request, and the server responds to that GET request
> as its first message after the protocol is upgraded,
> without any further bits needed from the client.
>
> IOW, waka (or some future HTTP/2.0) can be bootstrapped
> at near-zero cost with Upgrade because waka knows how
> to respond to the semantics of GET.  The same applies to
> any other valid HTTP method -- the server must provide a
> valid answer to that request, in the syntax of the new
> protocol, after the 101 is sent (see 2616 sec 14.42).

That sounds nice in theory.

But that also means that if the protocol you're upgrading to can't 
implement GET semantics, you'll *need* to use a different method.

OPTIONS is defined as 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.2>):

"The OPTIONS method represents a request for information about the 
communication options available on the request/response chain identified 
by the Request-URI. This method allows the client to determine the 
options and/or requirements associated with a resource, or the 
capabilities of a server, without implying a resource action or 
initiating a resource retrieval.

..."

So it seems ok-ish to use OPTIONS to upgrade to websockets.

(I moved this over here because I'd like to understand whether P1/P2 
need to say more about this).

Best regards, Julian

Received on Friday, 21 January 2011 13:16:03 UTC