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

Greg Wilkins <gregw@intalio.com> Tue, 19 July 2011 06:20 UTC

Return-Path: <gregw@intalio.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 0F35E21F8669 for <hybi@ietfa.amsl.com>; Mon, 18 Jul 2011 23:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.776
X-Spam-Level:
X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 il3aJOIgoPLn for <hybi@ietfa.amsl.com>; Mon, 18 Jul 2011 23:20:30 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F48E21F8663 for <hybi@ietf.org>; Mon, 18 Jul 2011 23:20:30 -0700 (PDT)
Received: by vxi40 with SMTP id 40so3649473vxi.31 for <hybi@ietf.org>; Mon, 18 Jul 2011 23:20:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.67.180 with SMTP id o20mr4133492vdt.509.1311056429503; Mon, 18 Jul 2011 23:20:29 -0700 (PDT)
Received: by 10.52.115.103 with HTTP; Mon, 18 Jul 2011 23:20:29 -0700 (PDT)
In-Reply-To: <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> <E2FABEF5-6475-4E40-A680-5FCD99DBCB96@gbiv.com>
Date: Tue, 19 Jul 2011 16:20:29 +1000
Message-ID: <CAH_y2NF4W=sVNiDAgFQ98rVZu6gy89WMgCWVRcBnu0DO-zbbCA@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 06:20:37 -0000

On 19 July 2011 14:49, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Jul 18, 2011, at 12:50 AM, Greg Wilkins wrote:
>> I think we went with GET because Roy was not able to well communicate
>> his concerns.
> [...]
>  In any case, see [...] to wonder at how I failed to communicate my concerns.

Roy,
I didn't mean to imply that you didn't try to communicate your
concerns, nor that you were to blame for the failure of that attempt.
It may well be that I/we were not listening correctly.


> If you want to use HTTP over the Web's
> standard port, then you are subject to HTTP's definitions.

and that is something I fully agree with and have advocated long and
hard for in this WG.


> 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).

I believe that websocket usage will be just the same as other
webapplication usage in this regard.  Some will correctly reference
specific resources, while others will not.  I don't think the spec can
mandate against bad URI space design.


> 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.

Ok I think I'm getting you more now.   It is not that you want
WebSockets to give an immediate semantic final response to the GET
request, rather you don't want websocket to consider the 101 to be
that final response because it is by definition a non final response.
So you say that this could be resolved by the spec making it clear
that the event stream accesses by the ws handshake is semantically the
response to the handshake GET?

regards