Subject: [hybi] Input on draft-hixie-thewebsocketprotocol-75

From: Tim Bray <[email-masked]>
Date: Wed, 17 Feb 2010 15:06:43 -0800

1. Header representation

First, there's an inconsistency.  In section 1.7 and certain places in
sections 4 and 5, the messages are given only as octet streams given a hex
byte at a time.  In parts of section 4 and 5, the hex byte streams are
provided along with a "Note" showing the ASCII equivalent.  In Section 5.2,
strings are given followed by hex-byte sequences.   So, first of all, making
this consistent would be good.

Second, the protocol is careful to specify that headers must all be ASCII.
 I-Ds and RFCs are constrained in such a way that it is guaranteed that
ASCII characters can be represented.  Given these constraints, it is not
clear why representing ASCII headers as hex byte strings improves the
usability of the spec; why not simply represent them as themselves?

Third, the beginning of a Web Socket message is very similar to that of an
HTTP message; a status line, several headers with CR-LF separators and a
CR-LF-CR-LF terminator.  As an implementor, I'd like to know if I can use
one of the many existing good HTTP-message libraries.  I think the answer is
"Yes, as long as they don't do continuation lines and allow me to control
the order of the headers".  Wouldn't this be useful to have in the spec?

2. Section 4.2, steps 1-2

I'm not sure about the pseudocode. Suppose the sender wanted to send a
message payload of one byte, say value "77".  I believe the pseudocode, as
given, would require that the message be something 80 81 00 77?  My first
thought was that it would just be 81 77, but the pseudocode would induce
several errors in this case.  Why is the first byte necessary... if 4.2 step
2. substep 1 Said Let /length/ be the value of the low-order 7 bits of
/frame type/, then you could encode this as 81 00 77.

Now having read this several times, I guess it's the case that where there's
a message length, the length bytes also have to have their own mini-frame; a
leading byte with the MSB on, and a trailing byte with it off.  Why not say
so?

To help with this kind of thing, an example might be nice.

3. Framing

It would be useful to explain why it is that both clients and servers are
required to receive but discard frames which begin with a frame length.

4. Section 4.3, 6 Closing connection

I'm really having trouble understanding the first paragraph of 4.3.  There
seems to be a distinction between reporting the problem to "the user" and
"the script".  Are these defined concepts?  And the language about not
conveying in a distinguishable way needs some help: justification,
explanation, amplification.

Similarly, section 6 could use a little explanation of the differing
requirements placed on user agents and servers.

5. Header Name Matching

In 4.1, sections 12 and 13, exact matching is required on the Web Socket
Protocol headers in terms of order and case.  Then starting at step 15, the
headers are read and saved up, and their names downcased,  and matches for
"websocket-origin" and friends are allowed to happen case-insensitively and
in any order.   The requirements for the server in section 5 are not like
this.  Is this just Postel's-law defensiveness?  Once again, some
explanation would be valuable.

  -Tim

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 18 Feb 2010 00:24:01 +0000

Tim Bray wrote:
>    3. Framing
> 
>    It would be useful to explain why it is that both clients and servers
>    are required to receive but discard frames which begin with a frame
>    length.

It's been said that it's for forward compatibility with future
applications which will use binary frames for non-text data.

But that ignores something: An endpoint shouldn't be sending frame
types that the other end doesn't know about.  So there is no need to
specify how to discard binary frames, unless there is a general
principle of discarding frames with unknown type byte too.

In other words, binary frames don't need to be in the spec for that
reason.

One thing that *really* needs to be right early on is making sure
future proxies know the frame boundaries, for efficient forwarding.

If the spec didn't describe binary frame delimiting, we could find, in
a few years, that we'd have no choice but to use UTF-8 for everything,
even having to encode binary messages into Unicode text, simply
because some parts of the net would have proxies parsing WebSocket
frames and failing to forward anything else properly or with useful
timing/buffering.

That's not stated in the spec, but it's an implied consequence of the
binary frame rule being described that WebSocket-aware proxies will
probably apply it.  Perhaps it should be explicit.

-- Jamie