W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 21 Jan 2011 14:15:10 +0100
Message-ID: <4D3986DE.5080704@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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 

"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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC