Subject: Re: [hybi] Apples and Orangutans

From: Rob Sayre <[email-masked]>
Date: Fri, 10 Apr 2009 03:12:49 -0400

Ian Hickson wrote:
>  Personally I am interested in "Minimal, Event", but I don't see any
>  reason why we wouldn't also have the other models.

I am interested in "Minimal, Event" as well.

- Rob

---

From: John Fallows <[email-masked]>
Date: Fri, 10 Apr 2009 00:19:30 -0700

I am also primarily interested in "Minimal, Event".

Kind Regards,
John Fallows.

On Fri, Apr 10, 2009 at 12:12 AM, Rob Sayre <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
-- 
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sun, 12 Apr 2009 19:34:35 +0200

Me too.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 12 Apr 2009 15:04:46 -0700

> I am interested in "Minimal, Event" as well.

I like Minimal/Event too, although I am starting to think the  
WebSocket protocol may be a bit too minimal. I think adding an  
optional type field to the packet or to the initial negotiation would  
help independently developed client and server code coordinate, much  
in the way MIME types help HTTP clients and servers without the  
necessity to define every possible type up front or to couple a single  
client to a single server. Ethernet and IP include a protocol number  
in the packet, TCP includes a port number (associated with protocols  
by convention), and HTTP as mentioned has a Content-Type. Perhaps  
WebSocket could make use of the HTTP Content-Type to identify the type  
of WebSocket service being connected to, or else there could be a per- 
packet identifier, which would be leaning towards the "Message, Event"  
model.

Regards,
Maciej

---

From: Ian Hickson <[email-masked]>
Date: Sun, 12 Apr 2009 22:35:06 +0000 (UTC)

On Sun, 12 Apr 2009, Maciej Stachowiak wrote:
> 
> I like Minimal/Event too, although I am starting to think the WebSocket 
> protocol may be a bit too minimal. I think adding an optional type field 
> to the packet or to the initial negotiation would help independently 
> developed client and server code coordinate, much in the way MIME types 
> help HTTP clients and servers without the necessity to define every 
> possible type up front or to couple a single client to a single server. 
> [...] TCP includes a port number (associated with protocols by 
> convention)

WebSocket includes a path (from the ws:// URL), which is intended to be 
analogous to the TCP port number.

Does that address this particular point satisfactorily?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 12 Apr 2009 15:39:58 -0700

On Apr 12, 2009, at 3:35 PM, Ian Hickson wrote:

>> WebSocket

I'm not sure the path is a good choice for identifying the type of  
service available. HTTP has both a path and a type. The path is sent  
by the client and identifies the specific resource. The type is sent  
by the server and directs how the resource is to be interpreted. I do  
not think we can expect, for example, multiple chat services to use  
the same path format, but there may be multiple chat services which  
choose to use the same protocol-by-convention over WebSocket. Right  
now, there doesn't seem to be a good way to give this information to  
the client, in the same way that any arbitrary URL can tell the client  
that its contents are to be interpreted as XML or PDF or plain text.

Regards,
Maciej

---

From: Ian Hickson <[email-masked]>
Date: Sun, 12 Apr 2009 23:00:30 +0000 (UTC)

On Sun, 12 Apr 2009, Maciej Stachowiak wrote:
> > 
> > WebSocket includes a path (from the ws:// URL), which is intended to 
> > be analogous to the TCP port number.
> 
> service available. HTTP has both a path and a type. The path is sent by 
> the client and identifies the specific resource. The type is sent by the 
> server and directs how the resource is to be interpreted. I do not think 
> we can expect, for example, multiple chat services to use the same path 
> format, but there may be multiple chat services which choose to use the 
> same protocol-by-convention over WebSocket. Right now, there doesn't 
> seem to be a good way to give this information to the client, in the 
> same way that any arbitrary URL can tell the client that its contents 
> are to be interpreted as XML or PDF or plain text.

I don't understand why a 16bit integer solves the problem for TCP, but a 
string doesn't solve the problem for WebSocket. They seem exactly 
equivalent to me -- they identify the target of the connection, and by 
convention, the protocol that that target supports.

Why couldn't we exect multiple chat services to use the same path for 
their chat server, in the same way that multiple chat services written on 
TCP use the same port?

There's also plenty of precedent on the Web of including type information 
in the URL -- so much so, in fact, that some people find the path 
(specifically the "extension" part of the "filename" component of the 
path) more reliable than the explicit Content-Type data. There's also 
"well-known paths" like robots.txt, which, while suboptimal from HTTP's 
point of view, seem like they'd fit in well with WebSocket.

It's not really clear to me how we would expose the information in the API 
if we were to use something other than the path. It's not like most 
authors are going to care, or check to see what the remote end thinks it 
is speaking -- they'll connect to their own servers, or to well-known 
remote third-party servers, and just talk the protocol that that endpoint 
supports. The path is convenient in that we already have it and it seems 
like it's exactly where authors would put the distinction (just as they do 
today on the Web -- content negotiation is used far less than just 
different URLs for different types, after all).

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 13 Apr 2009 09:26:30 +1000

> convention, the protocol that that target supports.

The big difference is that for the web you only have 2 strings
while TCP/IP has an infinite number of 16 bit integers.

ie The TCP/IP model is that if you want a ssh and 2 ftp conversations
then you open one connection to port 22 and 2 connections to port 21

On the web, we are limited (or should be limited) to 2 connections,
so you can't open an arbitrary number of websockets.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 12 Apr 2009 16:36:15 -0700

> convention, the protocol that that target supports.

HTTP is a better analogy here than TCP in my opinion. The fact that  
TCP only maps ports to protocols by convention is not so great - we  
have to go to extra design effort to prevent cross-protocol attacks as  
a result.

> their chat server, in the same way that multiple chat services  

I think that would be a poor design in the same way as relying on the  
exact path of "/favicon.ico" or "/crossdomain.xml" is a poor design.  
For one thing, it would mean you can't host multiple chat services on  
the same host and port. That seems like an arbitrary limitation. Also,  
if your WebSocket service is running on the same host and port as your  
web service, you may not have a free choice of what path to use, since  
some may be taken.

> point of view, seem like they'd fit in well with WebSocket.

I think well-known paths are problematic and we should not design  
WebSockets around using it for everything. I cited two examples above  
where I believe you've stated on the record that well-known paths are  
a design problem. What is different about WebSocket that makes relying  
on well-known paths for everything a good idea?

It seems like extremely poor design to conflate the path (which  
identifies a specific resource) with the type (which identifies the  
*kind* of resource).

> if we were to use something other than the path.

Exposing the information in the API would be trivial. And additional  
callback, or a property on the WebSocket object guaranteed to be set  
by the time the first message is received, would both work OK. By  
comparison, XMLHttpRequest provides for type checking by exposing the  
HTTP response headers.

> It's not like most authors are going to care, or check to see what  
> the remote end thinks it

The rest of your argument is that most authors won't bother to check.  
It is true that most Web content authors don't currently check the  
type of XMLHttpRequest responses, except perhaps implicitly by using  
responseXML. However, until very recently there was no ability to  
connect to an unknown service via XMLHttpRequest since cross-domain  
support is a recent innovation that is still being deployed. Browsers  
check types all the time however (even though in various cases that  
information is not considered completely reliable). Browsers do not  
rely on hardcoded well-known paths to identify the type of the  
resource, and it's hard to imagine the Web working as well as it does  
if they did. One use case that we can foresee is a JavaScript library  
using WebSocket to connect to a chat service using a well-known  
protocol (perhaps someone will specify a protocol for Jabber over  
WebSocket). In such a case, it is much more likely that the protocol  
type will be checked than with hand-coded client code, since the  
library will want to report errors to the content author in a  
reasonable way rather than return garbage data.

Adding a protocol type would be a modest extension that is trivially  
added to the protocol and client-side API. It would add very little  
complexity to the case of connecting to a known service, but creates  
for the possibility of a sane way of connecting to unknown services.

Regards,
Maciej

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 13 Apr 2009 01:11:22 +0100

> then you open one connection to port 22 and 2 connections to port 21

That's separate connections, to the same service, not to separate
services.

If want to connect to different services on the same host, over TCP/IP
you typically need something like separate IP addresses (bad idea) or
a distinguishing "virtual host" header like HTTP's Host:.  Or
different ports, but then it's not a well known service and often
doesn't work over firewalls.

The analogous thing in WebSockets would be a path for the resource
being connected to, and a string/path to identify the service type.

However, I don't think there is really a need for the second string.

The first one is enough to identify both the resource being connected
to and the service type, in the usual ways that people assign
application-specific meanings to URLs.

-- Jamie

---

From: Ian Hickson <[email-masked]>
Date: Mon, 13 Apr 2009 00:11:43 +0000 (UTC)

On Sun, 12 Apr 2009, Maciej Stachowiak wrote:
> > 
> > I don't understand why a 16bit integer solves the problem for TCP, but 
> > a string doesn't solve the problem for WebSocket. They seem exactly 
> HTTP is a better analogy here than TCP in my opinion. The fact that TCP 
> only maps ports to protocols by convention is not so great - we have to 
> go to extra design effort to prevent cross-protocol attacks as a result.

WebSocket has built-in support for preventing cross-protocol attacks -- 
only trusted peers can send arbitrary data, everyone else is just 
disconnected before the server receives the data.

Why would HTTP be a better analogy? WebSocket really is just trying to be 
TCP for the Web. It doesn't really have anything in common with HTTP other 
than the handshake, and that's really a red herring.

> > their chat server, in the same way that multiple chat services written 
> > on TCP use the same port?
> 

Fixed URLs are bad in HTTP because it causes people who don't know that 
the resources exist to try to obtain them. They're also a bad idea because 
HTTP is split across multiple users, but the fixed URLs are per-host.

With WebSocket the first point doesn't apply -- we aren't talking about 
people connecting to arbitrary hosts, we're talking about a convention by 
which someone can guess what protocol a server speaks.

The second point need not apply either, since we don't have to lock the 
entire path down, we can just say that the filename, or the extension, or 
whatever, is where you put the protocol you're willing to speak. So if you 
want to write a chat server that speaks WebSocketJabber, you can make it 
available at:

   ws://example.com/~jsmith/chat.wsj

...or some such.

> the same host and port. That seems like an arbitrary limitation.

As shown above, this is not necessarily the case.

> Also, if your WebSocket service is running on the same host and port as 
> your web service, you may not have a free choice of what path to use, 
> since some may be taken.

That seems fine with just using the extension or filename part also.

> where I believe you've stated on the record that well-known paths are a 
> design problem. What is different about WebSocket that makes relying on 
> well-known paths for everything a good idea?

What I'm advocating for is more like extensions that fixed paths, but even 
for fixed paths I don't believe the disadvantages they have in the realm 
of HTTP actually apply in the realm of WebSockets.

> identifies a specific resource) with the type (which identifies the 

It's what pretty much every widely-used file system does. It's what 
authors understand. Content-Type has been pretty solidly shown to be a 
failed experiment, IMHO.

> > It's not really clear to me how we would expose the information in the 
> > API if we were to use something other than the path.
> 
> callback, or a property on the WebSocket object guaranteed to be set by 
> the time the first message is received, would both work OK.

Current API:

   socket = new WebSocket('ws://example.com/chat.dcp');
   socket.onmessage = function (e) {
     if (e.data != 'DCP') {
       error('The server mysteriously stopped speaking DCP!');
       socket.disconnect();
     }
     socket.onmesage = chatHandler;
   }
   socket.postMessage('DCP');

Explicit API:

   socket = new WebSocket('ws://example.com/chat', 'DCP');
   socket.onprotocol = function (e) {
     if (e.data != 'DCP') {
       error('The server mysteriously stopped speaking DCP!');
       socket.disconnect();
     }
   }
   socket.onmesage = chatHandler;

It doesn't seem to gain us much.

> By comparison, XMLHttpRequest provides for type checking by exposing the 
> HTTP response headers. [...]
>
> It is true that most Web content authors don't currently check the type 
> of XMLHttpRequest responses, except perhaps implicitly by using 
> responseXML.

So why should we bother?

> However, until very recently there was no ability to 
> support is a recent innovation that is still being deployed.

It's not like the people connecting to remote JSON resources using 
<script> ever considered that the remote script might not be JSON. They 
say "json" in the URL they connected to, and they assumed it would work.

> Browsers check types all the time however (even though in various cases 
> that information is not considered completely reliable). Browsers do not 
> rely on hardcoded well-known paths to identify the type of the resource, 
> and it's hard to imagine the Web working as well as it does if they did.

Browsers check types by sniffing more than anything, and rely on 
well-known paths quite a lot. I think it's a stretch to say that the check 
types "all the time". But this is academic, because the browsers are 
acting on the users' behalf, whereas these scripts are acting on the 
authors' behalf. As the subject line of this thread suggests, it's an 
apples and oranges comparison.

> One use case that we can foresee is a JavaScript library using WebSocket 
> to connect to a chat service using a well-known protocol (perhaps 
> someone will specify a protocol for Jabber over WebSocket). In such a 
> case, it is much more likely that the protocol type will be checked than 
> with hand-coded client code, since the library will want to report 
> errors to the content author in a reasonable way rather than return 
> garbage data.

Why is a trivial handshake not enough for this?

> complexity to the case of connecting to a known service, but creates for 
> the possibility of a sane way of connecting to unknown services.

I don't understand what value it adds.

For custom protocols, authors aren't going to want to worry about the 
details of an additional handshake after the one we require now. Why add 
anything at all, when you can do it all -- if you want it -- over the 
regular WebSocket channel?

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 13 Apr 2009 10:28:36 +1000

> go to extra design effort to prevent cross-protocol attacks as a result.

Good point.

I think the limitation for websocket is that the URL
is associated with the connection, while for HTTP it is associated
with the request.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 12 Apr 2009 17:40:18 -0700

On Apr 12, 2009, at 5:11 PM, Ian Hickson wrote:

>> TCP

WebSocket is quite different from TCP, since it has defined message  
boundaries whereas TCP is just a two-way byte stream. TCP is much  
lower level than HTTP or WebSocket, as it imposes no structure on the  
data stream at all. It is expected that protocols are built on top of  
TCP which provide the needed structure. I think HTTP is a good  
protocol to use as inspiration, identifying resources by URL and the  
server reporting their type has proven to be a very effective model  
for data resources and for request-response services on the Web, and I  
think it would be similarly effective for bidirectional messaging  
services. There is little reason to think that bidirectional messaging  
services are fundamentally different.

> which someone can guess what protocol a server speaks.

Or more importantly, verify that it is the protocol they expect rather  
than interpret the response as garbage.

>   ws://example.com/~jsmith/chat.wsj

Using part of the path to identify the type sounds acceptable to me,  
as long as we define what part of the path holds type information as  
part of the WebSocket protocol instead of leaving it completely ad-hoc.

> It doesn't seem to gain us much.

Putting type information in-bad is not very reliable. How can you tell  
a server that speaks DCP from one that happens to send that string DCP  
as the first message and doesn't have a convention of sending the  
protocol type as the first message. This also seems to be completely  
different from your path convention suggestion. Which do you think is  
the right way for WebSocket subprotocol identification, path or in- 
band messages? How will subprotocol identifiers be registered?

>> type

I explained below - we are offering the ability to connect to unknown  
services, something that XHR hasn't offered at all. Consider a  
WebSocket-based syndication service - it initally send you the current  
copy of the feed, then incremental updates as they come in. This would  
clearly be better in many cases than, say Atom over http + periodic  
polling. And it's the kind of service you would likely want to open to  
cross-domain access. But it seems pretty useful for Web-based feed  
readers that used the hypothetical Atom-over-WebSocket to tell that  
this is indeed what they are talking to, and to be able to distinguish  
it from Jabber-over-WebSocket or CalDAV-over-WebSocket instead of  
possibly displaying garbage data to the user. After all, the user  
typed in a random supposedly feed URL, and the reader can't just trust  
that to be right.

> say "json" in the URL they connected to, and they assumed it would  

Remotely embedding remote scripts in the hope that they are JSON is an  
example of a very bad way to do things that should not be replicated.

>> resource,

I can only think of one well-known path relied on by the browser I  
work on, that being favicon.ico. While in some cases sniffing is  
applied, in other cases the type information is authoritative. Most  
importantly, other than a few types considered to effectively mean  
"unknown", the type of the main resource is generally trusted.

> Why is a trivial handshake not enough for this?

It provides a positive network effect if everyone does the handshake  
the same way, thus it is preferable to have subprotocol negotiation  
built into the protocol. The cost of doing so is minimal. Even using  
part of the path would be adequate, although I think it is preferable  
for the server to state the protocol than for the client to request  
it. The latter allows for the possibility that the same service may  
change protocols, just as on the Web the same resource may change types.

> regular WebSocket channel?

Doing protocol negotiation in-band with everyone doing it differently  
is more error-prone than having a simple out-of-band mechanism. It  
could be as simple as an additional HTTP header in the WebSocket  
handshake response. I would consider in-band subprotocol handshakes to  
be a worse alternative than a defined path convention. Now, WebSocket  
could require the first messages exchanged to be subprotocol  
identifiers, and require something distinct from any subprotocol  
identifier (such as the empty string). But that seems worse in just  
about every way to defining out-of-band subprotocol identification.

Regards,
Maciej

---

From: Mark Lentczner <[email-masked]>
Date: Mon, 13 Apr 2009 09:46:09 -0700

Ian Hickson wrote:
>  Personally I am interested in "Minimal, Event", ...

> Me too.

....

Okay, I see that there is quite a bit of interest in the Minimal,  
Event space. I'm see how this comes from the view of what most Comet/ 
AJAX techniques are doing today on the web: Getting some piece of  
"update" information into a web-page that a user is viewing.

What I'm wondering is: How does one, given a Minimal, Event style  
protocol, handle when there are two or more widgets on the page that  
need updates? The home page view on Facebook, for example, has at  
least four separate areas being live-updated.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 13 Apr 2009 18:24:12 +0100

> least four separate areas being live-updated.

I imagine most systems use a multiple-subscriber pattern:

    The web client sends 4 comet-style requests for updates (one per
    widget), sometimes combining those into a single HTTP request
    carrying 4 comet-style encoded requests, sometimes using 4
    separate HTTP requests.  At most one of the HTTP requests will be
    a "long GET", waiting for updates to any of the widgets, or the
    long GET may be a separate request.

And I imagine a few use a single-subscriber pattern:

    The web client sends 1 request for updates for all the widgets,
    with the web server knowing which 4 widgets are present on that
    page.  That request is probably the same "long GET" (or long POST)
    which waits for updates to any of the widgets.

In both cases, events come back over a single long GET/POST (or
polling request) and are dispatched to the appropriate widget, by
whatever ad hoc addressing scheme.

For my own pages I'm combining multiple "group subscriptions" into a
hierarchy of address/etag pairs.  One compact request is enough for
the whole page if the server has that state in its group-subscription
cache, but it drops to encoding multiple requests when the server's
cache no longer has that information, or when the page is dynamically
modified to contain a different set of widgets.

My scheme is efficient when you have hundreds/thousands of widgets,
such as a table of information where every cell is individually
tracking some information, a screen full of sliders, and line/bar
graphs where you might update just a subset of the data from time to
time.  The etags allow the data to be present in the initially fetched
page and updated only when needed.

-- Jamie

---

From: Mark Lentczner <[email-masked]>
Date: Mon, 13 Apr 2009 11:36:55 -0700

On Apr 13, 2009, at 10:24 AM, Jamie Lokier wrote:
> ... and are dispatched to the appropriate widget, by whatever ad hoc  
> addressing scheme.
>
> hierarchy of address/etag pairs.
> ... My scheme is efficient when you have hundreds/thousands of  
> widgets,

How would such a think work over the model of WebSockets, where all  
you get is a single string per event?

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden

---

From: Ian Hickson <[email-masked]>
Date: Mon, 13 Apr 2009 19:41:11 +0000 (UTC)

On Mon, 13 Apr 2009, Mark Lentczner wrote:
> need updates? The home page view on Facebook, for example, has at least 
> four separate areas being live-updated.

The simplest solution is probably to start off a shared worker [1] and 
then have that worker open the WebSocket connection back to the server and 
simply have it broadcast updates to all the scripts that have connected to 
the shared worker.

[1] http://www.whatwg.org/specs/web-workers/current-work/

This would have the benefit of not increasing the number of connections 
even when the user opens more tabs, too.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 14 Apr 2009 09:02:14 +1000

> four separate areas being live-updated.

I see the "many widgets on one page" as just the simplest case of
a need for multiplexing events over a single transport.

Very few sites like facebook actually put multiple widgets on
the same page, since those widgets potentially come from different
untrusted sources (and in the igoogle example, you don't want your
hot-babe-of-the-day widget sneaking a peek at your stock-ticker
widget).

So normal practise is to put widgets into iframes that are
used as sandboxes to isolate widgets.

So the first challenge is to get events in and out of these
sandboxes before they can be multiplexed onto a common channel.

This has to be coordinated by the parent page, because by
definition the sandboxed widgets can't know if there are
other widgets around with whom they should be multiplexing.

View like this, multi-widgets on a page really becomes
multiple frames with communication needs to the same
domain.     Which in turn is just a specific case of
the problem of multiple frames, tabs and/or windows
on the same domain.

It may be that as well as multiplexing events for
different widgets on the same page, we need to multiplex
and/or distribute events for different instances of the
same widget on different pages.

These are some of the issues the open ajax alliance
is trying to deal with - but I'm out of touch with their
latest thinking.

Anyway, my point is, that when considering multiplexing
events onto the same transport, we could consider the
multi frame/tab/window issues as well.

cheers

---

From: Jonas Sicking <[email-masked]>
Date: Mon, 13 Apr 2009 18:29:20 -0700

>   socket.onmesage = chatHandler;

I agree with Maciej here. I think having explicit metadata information
regarding which protocol is being transferred is of value. Allowing
people to do the "RightThing" while still letting them do the
"EasyThing that doesn't get in the way of the RightThing" is of even
higher value.

If the API could be something like

socket = new WebSocket('ws://example.com/chat', 'DCP');
socket.onprotocol = chat_handler;

for the people that want checking. And

socket = new WebSocket('ws://example.com/chat');
socket.onprotocol = iKnowWhoImTalkingToAndDontNeedNoStinkingChecking_handler;

for the people that are using their own home-brewed protocol. This
could use some magic value as the type (a'la
"application/octet-stream") or leave out the protocol indicator
entirely.

I don't have an opinion on if this type should be transferred to the
server which would be responsible for the checking, or if the type is
transferred to the client which would do the checking, or if its
transferred both ways for added goodness.

But the point is that the type is transferred at a specified location.
And IMHO that specified location should be separated from other fields
with other purposes. My understanding is that the path is intended to
allow for several websocket services from the same origin, thus I
would prefer if the protocol is separate from the path.

/ Jonas

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 20:03:24 +0100

> you get is a single string per event?

You can overlay any protocol over that, just as you can overlay any
protocol on top of TCP.  That's why WebSockets is acceptable for
people who are happy to build everything on top themselves.

Unfortunately it does require a lot of code on top of WebSocket to do
the kind of updates I'm doing.  (Ironic as the point is network
efficiency and minimal updates).

How it would work over WebSockets for me is:

   - Wrap subscription requests as generic events, and update
     notifications too.  (Effectively: Multiple responses per request).

   - Assign request ids, so that updates could come in any order.

   - Send small updates directly, with rate limiting, and big updates
     (e.g. images and large HTML) as merely a notification that
     there's a new one, unless requested to send the new update fully.

   - Keepalive events every 20 seconds to keep NATs open, and to
     recover from network changes.  Only needed when no other events
     transferred.

   - Interleave independent event sources fairly to prevent starvation
     by a subset.

   - Split large events into multiple small events, so that large
     events (e.g. images and large HTML) don't block the timely
     updates of small ones.

   - Serialise all those events into a byte stream, using whatever
     byte stream protocol seems like a good idea.  (Probably done at
     the same time as large event splitting.)

   - Split the byte stream either on event boundaries, if the large
     event splitting is good enough, or on artificial boundaries if I
     need better information on progress of large events than
     WebSockets provides with its per-message callback.

   - Encapsulate the split byte stream into WebSocket messages.

   - Stick it back together at the other end, into independent streams
     of events, and each event is an independent stream of bytes.  Bit
     like HTTP :-)

Hmm.  So I could _use_ Websockets, but I'd have to implement quite a
lot on top of it in Javascript on the browser side, and also on the
server side.  I'm basically looking at it as TCP with slight differences.

If you want my hopefully desirable widgeting methodology
then you'd probably want to use my Javascript as it looks a lot to do
from scratch.

Now I don't mind writing all that today, because I need it anyway for
tunnelling over HTTP in existing browsers.

But it would be nice if the (imho highly desirable ;-) features from
my protocol were available to others without them needing yet another
big Javascript library in future browsers, and then only perhaps with
one web server and application backend.

>From the above, my guess is WebSockets look compelling for the "3
widgets on a page need updates" case, and for the "I like writing my
own protocols and having full control" case.

But they don't look compelling for "I want to write an attractive web
application with lots of updating documents and tiny widgets without
using a pre-existing application framework or large bit of
Javascript".

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 20:17:17 +0100

> multi frame/tab/window issues as well.

Interesting point.

This is another good reason to do multiplexing and connection sharing
in the browser itself, instead of in Javascript.

I personally have about 200 tabs open in 20 windows on 2 desktops,
most of the time.  That's perhaps unusual.  Mostly to different sites
- things I'm reading and want to go back to - but 10 tabs open to a
single site isn't uncommon.

If you have 10 tabs open to a single site, then you _must_ have the
flow of events (including large events like images) being independent
to each tab/window.

That's because each tab/window is expected to behave independently of
the others, even if the others get stuck, or are uploading/downloading
some big file.

You can do that by either:

   - The browser opens separate connections for each window/tab.

   - The browser shares connections for each window/tab and handles
     multiplexing automatically.  This requires the low-level
     protocols to support multiplexing.

   - The Javascript in every tab/window coordinates to somehow share
     connections.  This is extremely difficult to get right even when
     it's allowed by security rules.  What happens when the Javascript
     for the first tab/window is closed and it's acting for all the
     others?  Messy.

The same applies for IFRAMEs to different sites.  However, multiple
tab/window is surely even more popular.

(The same also applies to different parts of a page being authored by
different people using different Javascript frameworks, so not using
Javascript-level shared dispatch protocol.  But that's been covered
before.)

Right now, the browser handles sharing HTTP connections automatically
and mostly transparently.  This is good.

I think it should handle sharing of whatever else we're proposing too,
for all the advantages which come from that instead of forcing rather
complex Javascript implementations to do it badly - or fail to do it
reliably at all in many cases.  (Most Javascript authors are not experts).

The only realistically usable alternative is lots of separate
connections, and apart from anything else, that's a waste of
resources.  We're not talking 3 connections here, we're talking 100
idle connections for a single busy browser (10 tabs, 100 widgets from
10 different authors per tab).  Which is absurd, and won't scale over
the internet's NAT routers, let alone the actual computers and
connection setup time :-)

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 14 Apr 2009 20:22:33 +0100

> "application/octet-stream") or leave out the protocol indicator

I agree with all of this.

Think of it as really basic optional type-checking.

Handy when you're connecting to _someone else's_ service URL, which
might have been supplied by a random user.

It's also handy for protocol negotiation in future, if any protocols
are standardised it gives you a change to try for the favoured one
first then fall back, even if the standardised protocols forgot to
include any negotiation themselves.  (Or in other words: they don't have to).

> transferred both ways for added goodness.

I say send it to the server, which can check and refuse.  Same as the
URL.  That lets the server accept more than one protocol.

> would prefer if the protocol is separate from the path.

Same reasoning here.  If the type is optional that's good for the
folks who don't care too.

Or instead of protocol type, a WebSockets method to add arbitrary HTTP
headers to the UPGRADE request, similar to XHR?

-- Jamie

---

From: Mike Dierken <[email-masked]>
Date: Tue, 14 Apr 2009 12:38:12 -0700

>     for the first tab/window is closed and it's acting for all the
Yes - this is something I ran into many years ago and indeed gets
messy. Having the browser (or other user-agent) do this sort of heavy
lifting would be great.

---

From: Jonas Sicking <[email-masked]>
Date: Tue, 14 Apr 2009 14:33:20 -0700

One thing that I forgot to include in my previous post was *why* I
thought that it was valuable with some basic semantic information :)

One aspect is the one Jamie is bringing up. We could allow for
protocol negotiation without having to have explicit support for that
in each protocol.

You could also imagine firewalls wanting to block some protocols,
either using white lists or black lists. While I'm personally not a
fan of companies filtering the actions of their employees, I do think
it should be allowed, and more importantly, trying to prevent it is
going to be unsuccessful at best, and harm the protocol at worst.

Security proxies could be made websocket aware and do filtering based
on the protocol that's used over websocket. Imagine that a chat
protocol becomes popular and that that chat protocol has the ability
to transfer files. A security product could scan such files for
viruses and malware if it knows how files are transferred. As I
understand it there are similar products for HTTP traffic. It'd be
much better for everyone involved if corporations did this rather than
block the chat protocol, or websockets, entirely.

I'm not sure that I can't think of a reason to do this, but in theory
a proxy could translate from one protocol to another if it knows what
protocols are being used.

The multiplexing channels issue that has been discussed in this and
other threads is also interesting. However I'd probably say that for
the initial version of the protocol we do not need support for having
UAs or proxies multiplex several connections into one transparently,
as long as we ensure that we can add support for that in a future
version if the need should arise.

/ Jonas

---

From: Frank Salim <[email-masked]>
Date: Tue, 14 Apr 2009 19:33:00 -0700

I think that connection sharing and coordinating amongst tabs is well
served by workers, as Ian pointed out. I do not think it should affect
the protocol design.

> What happens when the Javascript

I believe this is addressed by workers.

> efficiency and minimal updates).

Code is not bytes on the wire! Addressing your use case in the
protocol makes everyone pay for the features you need, and the cost is
bandwidth instead of code. It is better to address them at a higher
layer with another protocol (AMQP? BEEP?). Likewise, the multiple
widget case is best served by an application protocol with
publish/subscribe semantics.

> using a pre-existing application framework or large bit of

I think that this is correct. However, I think that there is nothing
wrong with using JavaScript to implement an application protocol. This
will be reusable code that is cached in CDNs. It will be much like
using a library that implements a protocol in C.

-Frank

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Apr 2009 19:36:06 +1000

> served by workers, as Ian pointed out. I do not think it should affect

Frank,

while workers might make such sharing technically possible, I think there
is still an issue since the websocket API is both an application API
and a protocol API.    Developers who just want UTF-8 datagrams and
don't care about the transport will use the websocket API directly and
will thus inadvertently make a decision about the creating a connection
to the server!.

Even XHR abstracts the requests made away from the connections used.

I think in this regard websocket API is a step in the wrong direction
as it makes the developer directly request a connection.   Instead
they should be directly requesting a channel and it should be up to
the browser to decide if that is a new connection or a shared multiplexed
connection.

At the very least, it should provide an SPI so that frameworks can
get underneath the users trying to consume datagrams and manage
the connections for them.

regards

---

From: Mario Balibrera <[email-masked]>
Date: Wed, 15 Apr 2009 09:42:37 -0700

Greg Wilkins wrote:
I think there
and a protocol API.

Frank's point is that WebSocket is _not_ an application API. Despite the
migration of this thread (from "Apples and Orangutans" to "Addressing
Minimal Events"), we're still discussing every proposal that comes up as if
it fit in the same layer. Do socket.send and socket.recv constitute an
application API? I mean, come on guys, why can't my socket speak XMPP and
support transactions?

GW:
Developers who just want UTF-8 datagrams and
don't care about the transport will use the websocket API directly and
will thus inadvertently make a decision about the creating a connection
to the server!.

In 99% of cases, this is not a problem. Any server supporting a streaming
connection -oriented application will not be affected if a user has 2 or 10
or 20 connections open instead of 1. And you know what? If someone really
needs his 1000 connections multiplexed, he can implement that on top of
WebSocket, because it is a _transport_ protocol.

Mario Balibrera

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Apr 2009 09:29:33 +1000

Mario Balibrera wrote:
> In 99% of cases, this is not a problem. Any server supporting a 
> streaming connection -oriented application will not be affected if a 
> user has 2 or 10 or 20 connections open instead of 1. And you know what? 
> If someone really needs his 1000 connections multiplexed, he can 
> implement that on top of WebSocket, because it is a _transport_ protocol.

I have to disagree on both counts.

It is my experience in deploying many Comet Ajax Push applications that
scalability is limited either by message rate (for apps like stock tickers)
or by number of connections (apps like auctions, IM and/or chat).
Connections are a big problem and will only become more so if creating them
become easier.

Websocket has a transport protocol, but it also has an API designed
to be used by javascript developers that directly relates to that
transport.   Developers will directly use that API from applications
and frameworks.    If sockets are to be shared, then it will have to
be as a result of those applications and frameworks voluntarily and
explicitly taking part in some multi-plexing scheme - just like in
the good old days when multi-tasking was done by applications
voluntarily giving back the CPU!

Connections are a real problem and I believe that the Websocket
API will encourage the usage of more sockets.

cheers

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Apr 2009 10:19:15 +1000

What I find interesting is that these are all API / implementation /  
policy issues, not wire protocol issues.

I.e., based on what I've read so far, "minimal, event" can be achieved  
by HTTP on the wire using Comet (perhaps with best practices /  
extensions to augment it); it's mostly the browser-side model for  
using HTTP that needs work here.

I know that Ian (and others?) also want to allow someone more advanced  
to create a bespoke protocol that goes beyond "minimal events", but I  
think that discussion should be separated; i.e., don't assume that  
addressing minimal events requires a new wire protocol.

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 16 Apr 2009 02:27:56 +0200

On Thu, 16 Apr 2009 02:19:15 +0200, Mark Nottingham <[email-masked]> wrote:
> extensions to augment it); it's mostly the browser-side model for using  
> HTTP that needs work here.

That's just polling data over HTTP. There's an API specification for that  
already:

   http://dev.w3.org/html5/eventsource/

> addressing minimal events requires a new wire protocol.

I might be missing something but I thought this was about bidirectional  
minimal events.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Apr 2009 10:32:55 +1000

On 16/04/2009, at 10:27 AM, Anne van Kesteren wrote:

>> I.e., based on what I've read so far, "minimal, event" can be  
>> achieved by HTTP on the wire using Comet (perhaps with best  
>> practices / extensions to augment it); it's mostly the browser-side  
>> model for using HTTP that needs work here.
>
> That's just polling data over HTTP. There's an API specification for  
> that already:
>

Thanks, wasn't aware of that one.

>> I know that Ian (and others?) also want to allow someone more  
>> advanced to create a bespoke protocol that goes beyond "minimal  
>> events", but I think that discussion should be separated; i.e.,  
>> don't assume that addressing minimal events requires a new wire  
>> protocol.
>
> I might be missing something but I thought this was about  
> bidirectional minimal events.

Does anything need to be said -- at a protocol level -- about sending  
events in the other direction over HTTP?

---

From: Frank Salim <[email-masked]>
Date: Wed, 15 Apr 2009 17:53:14 -0700

> API will encourage the usage of more sockets.

WebSockets are not subject to the browsers' restrictions on the number
of HTTP connections. I don't think this is a problem.

-Frank

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 15 Apr 2009 18:46:26 -0700

> the browser to decide if that is a new connection or a shared  

These are dead-on and an example of where, if the very commonly used  
features are part of the protocol, then the infrastructure can do a  
better job of handling the traffic.

Developing a protocol with an understanding of addressing of the bi- 
directional flow so that the infrastructure, being client environments  
(browsers being but one), proxies, caches and server frameworks can  
make different tradeoffs to achieve efficiency would be a great outcome.

This discussion seems convincing that clear abstraction of the  
interaction, and visibility of addressing would be of benefit to the  
infrastructure. Seems to me likely that meta-data (especially  
caching), content-type, and transfer encoding (especially chunked)  
would also be of benefit to the infrastructure.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden

---

From: Jonas Sicking <[email-masked]>
Date: Wed, 15 Apr 2009 19:34:47 -0700

On Wed, Apr 15, 2009 at 6:46 PM, Mark Lentczner <[email-masked]> wrote:
> features are part of the protocol, then the infrastructure can do a better
> job of handling the traffic.
>
> Developing a protocol with an understanding of addressing of the
> bi-directional flow so that the infrastructure, being client environments
> (browsers being but one), proxies, caches and server frameworks can make
> different tradeoffs to achieve efficiency would be a great outcome.
>
> This discussion seems convincing that clear abstraction of the interaction,
> and visibility of addressing would be of benefit to the infrastructure.
> Seems to me likely that meta-data (especially caching), content-type, and
> transfer encoding (especially chunked) would also be of benefit to the
> infrastructure.

Do you, or anyone else, have suggestions for concrete changes to the
current websockets draft?

/ Jonas

---

From: Ian Hickson <[email-masked]>
Date: Thu, 16 Apr 2009 05:01:30 +0000 (UTC)

> events in the other direction over HTTP?

I don't understand the relevance of HTTP to this discussion. HTTP is about 
requests/response for REST-like sets of resources. The model that I'm 
interested in here is bidirectional full-duplex arbitrary data transfer, 
typically without any resources (in the REST sense) being involved. For 
example, for a multiplayer game, sending user commands and receiving 
continuous game state updates.

Trying to adapt HTTP to this purpose seems to me to make about as much 
sense as trying to adapt a library catalogue system for use as a telephone 
interchange.

---

From: "S. Mike Dierken" <[email-masked]>
Date: Wed, 15 Apr 2009 22:57:23 -0700

If I were writing a multi-player game, I'd definitely want to identify
portions of game state and media assets with something like a URI, have
various standardized content types, consistent methods (uniform interfaces),
etc. So HTTP concepts sound helpful.
The part that would really suck would be to do all this with a single
connection - having both machines talking to each other at the same time on
a single connection doesn't work with HTTP (receiving media assets like
textures would block outbound messages or higher priority inbound messages).
I'm not sure having two connections would help - it might, but I don't know.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ian Hickson
> Sent: Wednesday, April 15, 2009 10:02 PM
> To: Mark Nottingham
> Cc: [email-masked]
> Subject: Re: [hybi] Addressing Minimal Events
> 
> I don't understand the relevance of HTTP to this discussion. 
> HTTP is about requests/response for REST-like sets of 
> resources. The model that I'm interested in here is 
> bidirectional full-duplex arbitrary data transfer, typically 
> without any resources (in the REST sense) being involved. For 
> example, for a multiplayer game, sending user commands and 
> receiving continuous game state updates.
> 
> Trying to adapt HTTP to this purpose seems to me to make 
> about as much sense as trying to adapt a library catalogue 
> system for use as a telephone interchange.
> 
> -- 
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 15 Apr 2009 23:57:52 -0700

On Apr 15, 2009, at 6:46 PM, Mark Lentczner wrote:

> directional flow so that the infrastructure, being client  
> environments (browsers being but one), proxies, caches and server  
> frameworks can make different tradeoffs to achieve efficiency would  
> be a great outcome.
>

It seems to me that if WebSocket is extended to support subprotocol  
negotiation, then in the future we could develop a Multiplexed- 
WebSocket-Over-WebSocket protocol and user agents could use it  
transparently when available to handle multiple channels from the same  
security origin to the same host/port. Nothing about the API directly  
exposes the wire protocol format or the fact that there is a dedicated  
TCP socket. This is part of why I think subprotocol negotiation is  
essential even for the first version of the spec, but multiplexing is  
not.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Apr 2009 17:17:42 +1000

> I don't understand the relevance of HTTP to this discussion. 

HTTP is our starting point.

It is how our browsers initiate connections
It is the protocol that is most likely to get through firewalls
It is a brilliant example of how an extensible flexible protocol can
adapt to changing usage.

So if you want to have a bidirection full-duplex protocol, then the
chances are the connection will be created by a HTTP client talking
to a HTTP server and then doing an upgrade.

For that upgrade to be successful, we are going to need to engage
all the firewall/gateway/proxy/cache venders and developers so that
they will support upgrade either to a specific protocol or to
a class of protocols.

Websocket has been put forward as a candidate for being such
a specific protocol.     However, while there is a lot of goodness
in websocket, I don't think it has the extensibility and flexibility
needed for it to be successful as the only available upgrade target.

If websocket is just one of many possible upgrade targets, then
I don't think that is a problem and websocket can continue to focus
on it's prime use-cases.    However, if websocket is to be the
only widely supported upgrade protocol, then I think it needs to
learn some lessons from HTTP as to how to keep most people mostly
happy most of the time.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Apr 2009 17:19:42 +1000

Frank,

Avoiding the limit doesn't avoid the good reasons the limit was put there
in the first place.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 16 Apr 2009 17:37:38 +1000

> current websockets draft?

Jonas,

certainly:

Support for a frame type that supports meta data plus
binary content in a standard format (HTTP-style would be fine).

Support for multiplexing datagrams over a single connection.
This could be on a subset of the datagram types (eg all those
with high bit of frame type vale set would have a channel number
sent and then the normal frame).

Decouple of the javascript API from connection state.  Javascript
developers should be able to develop against a datagrams centric
API and not be concerned if they are given a dedicated connection
or a multiplexed connection.

readyState, onopen, onclose and disconnect() should be on a separate
interface to onmessage and postMessage().  Frameworks and/or browsers
should have the opportunity to manage connections and use a
multiplexing datagram type.

A readable structured specification in RFC style rather than
narrative style (eg 1 send 0x00, 2, encode data, 3. send 0xff)

I'm happy to write these up in more details. Where is the best place
to send such feedback?   Also where is the latest draft of the
spec - I can find numerous versions, but all a little different.

regards

---

From: Mark Lentczner <[email-masked]>
Date: Thu, 16 Apr 2009 09:31:55 -0700

> current websockets draft?

I'm putting together a draft, incorporating many of the ideas and  
thoughts I've read here. However, it is more in style to my Reverse  
HTTP draft[1], than WebSockets. It will incorporate HTTP message  
semantics, bidirectionally, synchronicity, request/response and event  
support. I think it will do all that without being significantly more  
complex than HTTP, and do so by making use of the bulk of the HTTP spec.

Give me about a week or so....

	- Mark

[1] http://tools.ietf.org/html/draft-lentczner-rhttp-00

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden

---

From: Jonas Sicking <[email-masked]>
Date: Thu, 16 Apr 2009 10:53:29 -0700

> spec - I can find numerous versions, but all a little different.

I believe the latest version can be found at
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol

As I understand it feedback is supposed to go to the list we're
currently talking on.

/ Jonas

---

From: Frank Salim <[email-masked]>
Date: Thu, 16 Apr 2009 11:44:35 -0700

There are different reasons for imposing a limit on the number of HTTP
connections. A page with 100 images might innocently cause 100 HTTP
connections to open simultaneously. A malicious page might
intentionally do the same with embedded content.

In the case of malicious cross-origin connections, a WebSocket server
should have all the information it needs to close them quickly.

As far as client-side congestion goes, we leave it up to authors to
police themselves regarding their CPU usage and memory consumption.
Badly behaved sites get complaints and drive away their users. I see
this the same way.

-Frank

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 16 Apr 2009 22:57:27 +0100

> etc. So HTTP concepts sound helpful.

I agree.  But I know some people don't want those concepts; to them,
they are overhead.  I'm leaning towards a protocol which makes the
concepts easily available (and I think most people will use them), but
makes them optional.

> I'm not sure having two connections would help - it might, but I don't know.

That's why we talk about multiplexing and flow control.  A large media
asset does not block small messages over a well designed multiplexing
protocol, if it's also well implemented.  It does delay them a bit,
but the same happens with separate connections (with different
charactistics in detail).

If you've ever made a tunnel using "ssh -R" or "ssh -L" you'll have
seen this working ok.

You might be thinking of HTTP pipelining, where large assets do block
everything; that is one of many problems with HTTP pipelining, which
is why I don't like it :-)

Actually I lied.  For a game you would might benefit from two TCP
connections with IPTOS = INTERACTIVE and IPTOS = BULK, to help
separate the streams and improve prioritising at routers.  That isn't
in the WebSockets API at the moment.

(Though a _really_ real-time game would use UDP anyway...)

Having two connections isn't a problem.  Having many connections (say
20) is worse for delays, if they are all active.  It tends to increase
packet delivery jitter for all of them, making TCP's heuristics less
effective.

Also you need to send 2*number_of_connections keepalive packets every
30 seconds or so to keep NATs open.  With many connections that adds up.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 16 Apr 2009 23:12:54 +0100

> they will support upgrade either to a specific protocol or to

That's one way, but there are other more current-proxy-compatible ways
to do it.  They are hacks, but work.

-- Jamie

---

From: Mario Balibrera <[email-masked]>
Date: Thu, 16 Apr 2009 16:29:26 -0700

I think an important fact is sort of being overlooked here. When you add
something new to your toolset, the rest of your tools don't disappear. If
your application needs to transmit a file, you should consider using a
protocol designed for that exact thing: HTTP. Of course, you can send
anything you want over your streaming connection, but if for your particular
application some other tool is a better fit, don't be shy! Consider how XMPP
decided to support buddy icons (http://xmpp.org/extensions/xep-0084.html).
They thought it was best to provide two options: you can either send the
file over the wire, or simply transmit a url.

As Jamie points out, another solution involves separate connections, which
rather makes sense, as game logic and images will very likely be on separate
servers.

No one here is proposing eliminating HTTP. Ideally, these discussions will
produce something that perfectly complements it - that fills in where HTTP
is lacking without too much overlap. That said, I certainly don't mean to
suggest that HTTP has no place in this conversation (WebSocket, after all,
uses HTTP conventions to establish a connection). I simply think that every
feature of HTTP doesn't necessarily belong in the protocol we choose to sit
beside it, and that the various features of HTTP will continue to work, even
if we settle on Streaming Pig Latin Sockets.

As Frank pointed out, giving developers a flexible tool is a GOOD IDEA, and
if we don't, they'll just end up hacking out the features they would have
implemented reasonably given something more general (see: Comet).

Mario Balibrera

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 17 Apr 2009 15:51:30 +1000

> As I understand it feedback is supposed to go to the list we're

Great!

Then I reiterate my last feedback - the spec is
written is a way that is very difficult to understand.

I'm sorry to be critical of the document - as I know it
is exceedingly difficult to write good specifications
that are both understandable and precise, while not
be too prescriptive of things like ordering and algorithms.

The spec really needs to have the key concepts described
in introductory sections rather than by pseudo code
repeated several times in the body of the document.

For example, if I want to find out what the frame type byte
is, I have to go to section 3.2   where I learn that
it is the first byte read when reading bytes from the
server.

But to know what that byte means, I then need to step
through the pseudo code of what to do if high bit is
set and then mentally run the iterations in order to
work out what it means.

I think have to read the same pseudo code in section 4.2
to see if the server implements the same state
machine(s) and thus has the same framing.  I'm still not
sure if the framing of 3.2 and 4.2 are exactly the
same?

It would have been so much simpler just to say:

3 Protocol Parameters

   ...

   3.x Frame Type

   The first byte of any websocket message is the frame type,
   which is used to indicate both the content type and framing
   of the messasge. Frame types 0x00 to 0x7f (high-order bit clear)
   represent sentinel framed data. Frame type 0x00 to 0x7f (high-order
   bit set), represent length encoded framing.

   3.x.1 Known frame types

   0x00  sentinel framed UTF-8 data
    ...   ????
   0x80  length encoded framed UTF-8 data

4 Web Socket Message

   4.1 Sentinel Framing
   Blah blah blah 0x00 blah blah blah 0xFF

   4.2 Length Encoded Framing
   First bytes represent the message length
   encoded as a variable length integer.  Each byte contributes
   7 bits to the length and the first byte with the high-order bit
   set is the last of the length bytes.

Another problem is that the handshake is defined by
explicitly saying what bytes to send: eg:

    5.   Send the following bytes to the remote side (the server):
            47 45 54 20
         Send the /resource name/ value, encoded as US-ASCII.

         Send the following bytes:

            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

         NOTE: The string "GET ", the path, " HTTP/1.1", CRLF, the string
         "Upgrade: WebSocket", CRLF, and the string "Connection:
          Upgrade", CRLF.

     6.  Send the following bytes:
            48 6f 73 74 3a 20
         Send the /host/ value, encoded as US-ASCII.

         Send the following bytes:
            0d 0a
         NOTE: The string "Host: ", the host, and CRLF.

    7.   Send the following bytes:
            4f 72 69 67 69 6e 3a 20
         Send the /origin/ value, encoded as US-ASCII.

         NOTE: The /origin/ value is a string that was passed to this algorithm.

         Send the following bytes:
            0d 0a
         NOTE: The string "Origin: ", the origin, and CRLF.

That's a really long winded way of saying send a HTTP/1.1
request with some headers set.   More over, that specification
implies that the order has to be:

  GET /path HTTP/1.1
  Upgrade: WebSocket
  Connection: Upgrade
  Host: acme.com
  Origin: origin

and thus it would be illegal to send:

  GET /path HTTP/1.1
  Origin:                origin
  Host:
    acme.com:80
  Upgrade:                 WebSocket
  Connection:      Upgrade

This is a perfectly legal HTTP request and should
be able to be accepted to initialize a websocket
upgrade.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 24 Apr 2009 10:43:35 +1000

Jonas, Ian,

just to continue on expanding my feedback on websocket

It would be great if the websocket proposal could include
standard definitions for mime encoded datagrams.

Current frame types are:

   0x00  - sentinel framed UTF-8 message
   0x80  - length framed binary data.

I'd like to see two additional frame types supported
by default:

   0x01  - sentinel framed UTF-8 encoded MIME message
   0x81  - length framed MIME message.

Both these data types would contain a data that commenced
with a standard mime header (RFC 2045).   The header is optional
and terminated by CR LF CR LF.  Thus these types have a minimal
overhead of 4 bytes.

For both these types, any Content-Length header will be
ignored and the length indicated by the websocket framing
minus the header length will be used.

For 0x01 types the content type is assumed to be "text/plain; charset=utf-8"
If a content type header is specified, it must be "text/????; charset=utf-8"

For 0x81 the content type is assumed to be application/octet-stream unless
otherwise indicated.

The websocket API would need to be slightly extended to support some
common types of message.

I would suggest that onmessage always be called for all text
mime types, but with some additional parameters: eg.

   onmessage(text,mimetype,headers)

The browser would be responsible for converting the transported
charset to the charset of javascript. If the conversion could not
be done, then the message would be discarded.

Additional events could be supported if you want the browser/server
to do the parsing for your.   For text/xml & text/html:

   ondocument(dom,headers)

and for text/json

   onobject(object,headers)

To send such messages, the API would also need to support

void postMessage(data,headers);

I think this is a minimal change to websocket and would go a long
way to address many of the concerns raised here.    With the ability
to send standardized meta data, then the job of coming up with
standardized multiplexing is much much simpler.

cheers