[whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Jonas Sicking wrote:
> On Fri, Aug 7, 2009 at 10:07 PM, Greg Wilkins<gregw at mortbay.com> wrote:

> Out of curiosity, what advantages do you see with having a declared
> content-type? I can think of a few, but wanted to know which ones you
> had in mind.

There are several reasons and use-cases.

Firstly, it's always good to be self describing, so that assumptions
can be checked and errors/incompatibilities quickly discovered.

I also dislike the "favoured son" status of utf-8 in the websocket
protocol proposal.  Who's to say that other charsets might not be
better for some purposes or that utf-8 might be replaced in the
lifespan of the protocol.

While not supported by the current js API, I can see imagine uses
for a stream of media datagrams (sound bites or chat room avatars).
It would be good to be able to mix JPG, PNG etc in the same stream.

Currently with XHR in JS, the browser can use the content type
to parse a response into XML DOM, HTML, JSON etc.   I can imagine
extensions to the websocket API that would use similar capabilities.


> Also, what do you mean by "orderly close"?

Currently one of the pain points in HTTP is that a server can
close a connection at any time.  So browsers need to be careful
when reusing an idle connection as the server might close it
just as a new message is sent - then the browser does not know
if the message was received or not, so we get the different
handling for POST vs GET (idempotency etc.).

So what I proposed in BWTP is to support an orderly close
interaction, so that a client, server OR intermediary can
initiate a close of the connection without losing any
in transit messages.

Of course, connections can still fail without orderly
close - but that will be seen as a real failure rather
than a happenstance of normal operation.




> As far as specification style (BNF or not), I personally don't really
> care there, as long as it's well defined how to handle all possible
> inputs, valid or invalid.


One aspect of the websocket protocol spec that I don't like, is
how it specifies the protocol as an algorithm that is step
by step and includes exact hex pattern of some of the messages.
eg


   6.   Send the following bytes to the remote side (the server):

        47 45 54 20

        Send the /resource name/ value, encoded as US-ASCII.

        20 48 54 54 50 2f 31 2e  31 0d 0a 55 70 67 72 61
        64 65 3a 20 57 65 62 53  6f 63 6b 65 74 0d 0a 43
        6f 6e 6e 65 63 74 69 6f  6e 3a 20 55 70 67 72 61
        64 65 0d 0a

   7.   Send the following bytes:

        48 6f 73 74 3a 20

        Send the /host/ value, encoded as US-ASCII.

        0d 0a

   8.   Send the following bytes:

        4f 72 69 67 69 6e 3a 20



which represents

  GET <resource name> HTTP/1.1
  Upgrade: WebSocket
  Connection: Upgrade
  Host: <host>
  Origin:

But it represents that exactly and does not allow
variation that is perfectly legal HTTP.

It would allow a server to reject a message
simply because it's headers are ordered differently
or if a just LF was sent instead of CRLF
or if there ever is a HTTP/1.2
or if some extra white space is included in the headers

So a server could reject:

  GET <resource name> HTTP/1.1
  Host:<host>
  Connection:Upgrade
  Upgrade:WebSocket
  Origin:

and a human debugger who is used to normal HTTP is going to
be very very confused why their legal HTTP request is
being rejected.

This strikes me as an unreasonable restriction to
have in the specification.  BNF specifications
can be a lot more forgiving.

It is also really hard to tell what the websocket
algorithm specifies.  Can you tell me if
3.2 Data Framing and 4.3 Data framing specify the
same framing or not?   The text is not the
same - so potentially the framing is different?

What if a client/server produces a legal
byte stream but that uses a different algorithm to
that specified (eg the bytes are buffered rather
that "sent" at each step).   Is that client/server
considered compliant to the specification?

Sorry for ranting, but I think the language and
style used by a specification is really important.


> Other than that I largely agree.

Cool!

cheers