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

Re: #300: Define non-final responses

From: Greg Wilkins <gregw@webtide.com>
Date: Mon, 18 Jul 2011 16:48:39 +1000
Message-ID: <CAH_y2NEC9d1xB6A3U7Zy6DkyEX1gjR7sAJkSZ7xR_aXE+N=eNg@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
On 18 July 2011 11:07, Roy T. Fielding <fielding@gbiv.com> wrote:
> Other protocols that do not want GET semantics, or some other such
> semantically significant method, should use something like OPTIONS
> for the request and specify how to respond to it.  That is what I
> told the hybi WG.

Roy,

Unfortunately your postings to the hybi list did not clearly express
your concerns with the use of Upgrade.     You have expressed them
much better here and I finally get it that you are concerned about an
outstanding semantic request.

However, I don't understand why an OPTIONS method is any better, as it
too is a semantic request for information (about the communication
options available on the request/response chain).   So even after a
101, there is a semantic response outstanding.

So at the very least, protocols like websockets need to deal with the
outstanding response.  However, as the wire protocol is entirely up to
the new protocol, surely it is an option for the protocol to use zero
bytes to "send" and implicit response to the user-agent.      Perhaps
it would be sufficient for the websockets spec to say that after a
successful upgrade, the user-agent that issued the upgrade request
should receive an implicit 204 response.
Received on Monday, 18 July 2011 06:49:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:45 GMT