Re: [hybi] Questions and comments on draft-hybi-thewebsocketprotocol-10

"Roy T. Fielding" <fielding@gbiv.com> Tue, 19 July 2011 04:49 UTC

Return-Path: <fielding@gbiv.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2195821F869D for <hybi@ietfa.amsl.com>; Mon, 18 Jul 2011 21:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOwr0QslwE26 for <hybi@ietfa.amsl.com>; Mon, 18 Jul 2011 21:49:15 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C7CC021F8698 for <hybi@ietf.org>; Mon, 18 Jul 2011 21:49:14 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 59808674058; Mon, 18 Jul 2011 21:49:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=YyQeg6urdrnRNA+y 68vxEkU0Gkat+qX6miDdS+/4P2OjnjNtrIPx7j+DlJbBa5FEdZjxIFMaDpdAmxUI rcVWShzCJeORK1FD19ZU5uFbuTfYg21Pnws5vpFQCg+NBYyXfHpJwTOM+E2QWx8s m5TuksQqMjjrhqgLzldsbS6aqd0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=iA8tlR1BbMe0cNA2/kdFl9riEDU=; b=2JFevivwdHBYJbInrEkWuDAxtQtB SR/L9cTwFtGjc8XVJTObNkSx2yBD5e1sIlzWd2CJlCJGmBiQDV2rhVhnIgc4U24A XRN5FaHJD4GTHaY6Vdwnn5nIcnL7DzNd1pGmspHkFB5cZ/8q9sKrwOpwXN8ymljj e9QIZ/YVqYT+i8A=
Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 1C222674057; Mon, 18 Jul 2011 21:49:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <CAH_y2NHf6=8-CN_CVUKy=KH7yRcm1_4jzQAf7jt=qpQBeFqbpw@mail.gmail.com>
Date: Mon, 18 Jul 2011 21:49:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2FABEF5-6475-4E40-A680-5FCD99DBCB96@gbiv.com>
References: <4C26A6A5-DA13-45A3-9DBA-D2515DF923CD@mnot.net> <CAH_y2NHf6=8-CN_CVUKy=KH7yRcm1_4jzQAf7jt=qpQBeFqbpw@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
X-Mailer: Apple Mail (2.1084)
Cc: Mark Nottingham <mnot@mnot.net>, "hybi@ietf.org HTTP" <hybi@ietf.org>
Subject: Re: [hybi] Questions and comments on draft-hybi-thewebsocketprotocol-10
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2011 04:49:19 -0000

On Jul 18, 2011, at 12:50 AM, Greg Wilkins wrote:
> On 18 July 2011 17:06, Mark Nottingham <mnot@mnot.net> wrote:
>> 1) I missed the end of the handshake saga; can someone speak to why GET was chosen over, say, OPTIONS? Roy seems to have strong feelings about that (see recent discussion on HTTPbis).
> 
> I think we went with GET because Roy was not able to well communicate
> his concerns.   He's done a better job in the recent thread in
> httpbis, and I now understand that he is concerned about the
> outstanding semantic GET.   However I still don't understand why he
> thinks OPTION is any better, as it still is a request that requires a
> semantic response.   

OPTIONS is a request for the communication options on the connection
for the target resource.  It is not a request of the resource itself;
it is a meta-request to be processed by the handler of that resource.
It should be obvious why completing the WebSocket handshake is a valid
response to that request if the Upgrade succeeds.  In any case, see

  http://www.ietf.org/mail-archive/web/hybi/current/msg05743.html
  http://www.ietf.org/mail-archive/web/hybi/current/msg05750.html
  http://www.ietf.org/mail-archive/web/hybi/current/msg05751.html

to wonder at how I failed to communicate my concerns.

> In either case I think that websockets should be
> free to define an implicit response (eg 204 No Content) is represented
> by a successful handshake.

GET has specific semantics regarding the state of the resource that is
the target of this request.  If you want to use HTTP over the Web's
standard port, then you are subject to HTTP's definitions.  It is not
that difficult for WebSocket to correctly use GET, as Henrik Frystyk Nielsen
just explained on httpbis, if the target resource is meaningful and not
some generic entry point (like those stupid SOAP gateways).

There is no need for an implicit response of "no content" if the result
of making the WS request via HTTP has application-level semantics that
are equivalent to a response to GET after WS takes over the connection.
For example, if the request results in an asynchronous event feed (the
feed named by that URI), joins the user to a running game (named by
that URI), connects the client to the video stream corresponding
to the eyes of a mini robot (named by that URI), etc.  WebSockets
merely needs to state that the client's HTTP request remains
outstanding after the 101 is sent and the WebSockets application is
responsible for handling and responding to that request in accordance
with the semantics of the target resource.

If that's too much to ask, WebSockets is welcome to define its own
unique method, use OPTIONS (and let the framing be the response), or
use a different port and a different protocol for the handshake.

....Roy