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

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Jul 2011 17:06:57 +1000

Hi,

I've just read through -10, and wanted to ask a few questions. These are NOT (yet) Last Call comments, as I haven't kept up with the hybi list for a while, and haven't reviewed a draft since around -06. 

In other words, I'd like to understand things a bit more before making LC comments; there may be good reasons for the few things I saw that raised my eyebrows.

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

2) The Upgrade token has no version; e.g., from the examples in 1.2:
    Upgrade: websocket
Why? The protocol version seems to be carried in the Sec-WebSocket-Version header; could it not be moved (or copied) to the upgrade token?

3) The last paragraph of 1.2 seems to be a bit of a non-sequiter; all protocols need framing, not just those used by event-driven implementations.

4) Section 3 defines two new URI schemes for WebSockets, but the handshake is entirely HTTP-based, and the default ports are HTTP's. Why is a new URI scheme needed here? I understand that client software needs something to trigger the upgrade from, but why use the scheme, instead of (for example) the API? Is it expected that WS: URIs will be used in other places URIs are used, such as in HTML elements like A / IMG / SCRIPT, or in browser location bars?

Having two URL schemes use the same default port doesn't feel right.

5) In the diagram at the start of 4.2, the dotted horizontal line in the left hand side of the "extended payload length continued" is a bit confusing, I think. YMMV.

6) In section 9.1., private-use-token is defined as having an "x-" prefix. This goes against emerging BCP, see draft-saintandre-xdash.

7) The contact field for registry entries in 11.13 is listed as [email-masked]'. Is that list going to persist? Common practice is to use [email-masked] AIUI.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 18 Jul 2011 17:50:28 +1000

> In other words, I'd like to understand things a bit more before making LC comments; there may be good reasons for the few things I saw that raised my eyebrows.

_this response is non-normative_

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

> Why? The protocol version seems to be carried in the Sec-WebSocket-Version header; could it not be moved (or copied) to the upgrade token?

I think we are only just coming around to the acceptance that we
really do need a version beyond the draft stage.  The version was put
in a header as it was originally only considered needed to distinguish
drafts.  If it is going to be there to stay, then perhaps the
protocol/version format would be better.

regards

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Jul 2011 10:07:59 +0200

On Mon, Jul 18, 2011 at 05:50:28PM +1000, Greg Wilkins wrote:
> outstanding semantic GET.

I would add that there was a GET very early in the specification, when
the protocol was not even HTTP compatible yet. It dates back the era
where it was desirable to use an HTTP-like protocol that was easy to
parse by a simple script. Now we're more in line with HTTP and despite
all the discussions on GET vs OPTIONS, it appeared that there was no
real preference for one vs the other, so it was suggested that this
would not change unless there is a valid reason.

> However I still don't understand why he

Alternatively we could consider that the server's hello is the response
to the request.

> protocol/version format would be better.

I too find it more useful to have the version in the Upgrade header than
anywhere else. For intermediaries it can be very useful to know the version
from the Upgrade header because they can decide what processing to start
depending on what they see there.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 18 Jul 2011 10:54:09 +0200

> Why? The protocol version seems to be carried in the Sec-WebSocket-Version header; could it not be moved (or copied) to the upgrade token?

I agree. But such version must be the definitive version (rather than
the draft revision or similar). So for example I suggest:

  Upgrade: websocket/1.0

The version "1.0" should not change in years until a complete new
WebSocket spec borns ("2.0").

> 4) Section 3 defines two new URI schemes for WebSockets, but the handshake is entirely HTTP-based, and the default ports are HTTP's. Why is a new URI scheme needed here? I understand that client so…

An URI is useful as it tells you in a single line the transport to use
("ws" => TCP, "wss" => TLS over TCP), the domain to resolve (or IP)
and optionally the port (or default port 80/443 if not present). Also,
in case of including DNS SRV support [*] an URI is the best way to
extract the data to query.

[*] http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02

> Having two URL schemes use the same default port doesn't feel right.

That's not true. Current websocket draft states that "ws" schema uses
port 80 by default while "wss" uses 443 (unless explicitly present in
the URI).

> 6) In section 9.1., private-use-token is defined as having an "x-" prefix. This goes against emerging BCP, see draft-saintandre-xdash.

I agree. "Those Who Ignore History are Doomed to Repeat It".
I expect authors would take care of it.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Jul 2011 15:35:58 +0100

>Hi,
Hi Mark,

>In other words, I'd like to understand things a bit more before making LC comments; there may be good reasons for the few things I saw that raised my eyebrows.
 [...]

>Why? The protocol version seems to be carried in the Sec-WebSocket-Version header; could it not be moved (or copied) to the upgrade token?
What is the value in duplicating the version in the Upgrade token?

>3) The last paragraph of 1.2 seems to be a bit of a non-sequiter; all protocols need framing, not just those used by event-driven implementations.
Yes, this can be reworded not to mention event-driven implementations.

 [...]

>7) The contact field for registry entries in 11.13 is listed as [email-masked]'. Is that list going to persist?
>
Yes. At least I would be surprised if it wouldn't.

>Common practice is to use [email-masked] AIUI.  
>
I think leave the WG mailing list is Ok. I wouldn't get stuck on this 
and if IESG thinks otherwise, we can change.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Jul 2011 16:46:30 +0200

Hi Alexey,

On Mon, Jul 18, 2011 at 03:35:58PM +0100, Alexey Melnikov wrote:
> >Why? The protocol version seems to be carried in the Sec-WebSocket-Version 
> >header; could it not be moved (or copied) to the upgrade token?
> >

I think it can be a easier for some intermediaries to decide what action to
take based on the Upgrade header alone, especially if a client supports 2
versions and the server responds with the selected one.

Regards,
Willy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 18 Jul 2011 21:49:13 -0700

On Jul 18, 2011, at 12:50 AM, Greg Wilkins wrote:
> 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

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

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 19 Jul 2011 16:20:29 +1000

On 19 July 2011 14:49, Roy T. Fielding <[email-masked]> wrote:
>> 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

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.

> 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