Subject: [hybi] WebSocket feedback

From: Ian Hickson <[email-masked]>
Date: Fri, 24 Apr 2009 09:51:40 +0000 (UTC)

Sorry about my absence from this list the past few days, I've been busy 
with HTML5 work. I put aside a few e-mails to reply to on the topic of 
WebSocket, which I reply to below:

On Mon, 6 Apr 2009, Peter Saint-Andre wrote:
> On 4/6/09 2:28 AM, Ian Hickson wrote:
> > What I'd like to work on is "TCP for the Web".
> 
> That's what we tried to define with BOSH. Whether we succeeded is an 
> open question.

I think reusing TCP's semantics (e.g. the tight coupling of the two 
directions of communication into one TCP channel) is important in making a 
"TCP for the Web" -- I don't think that a TCP analogue should map to 
multiple TCP connections underneath.

On Tue, 7 Apr 2009, Mridul Muralidharan wrote:
>
> Note that browser based javascript clients are not the only consumers of 
> bi-directional http; others like mobile clients, firewalled thick 
> clients, etc are also possible (and actually exist with BOSH for 
> example).
>
> So possibly targeting specific implementation technology might not be 
> appropriate for designing the spec ?

Why wouldn't mobile clients, firewalled thick clients, etc, just use a raw 
TCP socket?

The only reason we're not looking at raw TCP sockets when it comes to what 
to provide JavaScript Web apps access to is that TCP doesn't natively 
support the browser's security model. If it wasn't for that, raw TCP is 
exactly what we would have by now -- in fact the SVG WG even specced an 
API out for exactly that in SVG 1.2 (before the security problems with 
doing that were brought up).

On Tue, 7 Apr 2009, Sylvain Hellegouarch wrote:
> 
> In this context I can understand why your draft is so short and that's 
> probably a good sign because it'll be that easier to see deployed. 
> Nonetheless this long discussion makes me wonder whether or not having a 
> new protocol is a better idea than picking one of the existing 
> alternatives (Comet, BOSH). Wouldn't it be better to focus energy on 
> best practices when it comes to long polling connections based on what's 
> working now?

Adding something new doesn't prevent things that already work from 
working.

On Wed, 8 Apr 2009, Mark Lentczner wrote:
> 
> I see the attraction of just giving something very simple to application 
> developers. Giving them a protocol that does Minimal Events is easy to 
> explain and would have a simple API. However, I have seen that over 
> time, applications often need to build most of the framework that is 
> already provided by more complex abstractions. Where the cost of those 
> abstractions is small, and the ability to use them in simpler ways easy, 
> it is often better to supply a richer abstraction to all, since the 
> uniformity of the often implemented bits means better code for all.

That's what libraries are for. Core platforms (POSIX, Win32, Cocoa, the 
Web) provide fundamental building blocks, on top of which libraries are 
built that expose many different possible abstractions.

It's better that way, as it gives authors more choice as to how to do 
things. Someone might want a comprehensive protocol with all kinds of 
metadata and channels and reconnection support and so on; someone else 
might want a different set of abstractions based more on resources with 
identifiers and types. Why should we force one to use the protocol the 
other wanted? Better to provide an infrastructure on top of which both of 
these can be built.

Having said that, if people want higher-level protocols standardised, I've 
nothing against that.

> Example: Implementing a Minimal, Event protocol with Message, Req/Resp 
> is just a matter of accepting the overhead of the framing of the simple 
> data blob, and the cost of the minimal response message.

It also probably means dealing with a framework that's more than a hundred 
lines of Perl (say), which puts a lot of burder on the developer, and 
probably the inexperienced one at that.

> On the other hand, implementing a Message, Req/Resp. protocol with 
> Minimal, Events, means building a whole framework for encoding message 
> parts (address, meta-data and data) into the minimal data units 
> (strings? binary blobs?) and coming up with a way to correlate responses 
> to requests, etc... all in the application layer.

Right, but in this case it's likely the experienced developer.

On Thu, 9 Apr 2009, Peter Saint-Andre wrote:
> 
> The same-origin model is often invoked here. Is there a good definition 
> of it? Perhaps it would be helpful for someone to write a small I-D 
> about this.

The HTML5 spec defines it formally, but I don't know of a simple 
introduction to it.

Basically it consists of partitioning untrusted code based on tuples that 
consist of hostname or IP address, port, and protocol (scheme). Code is 
then limited to dealing with resources from the same origin (with some 
historical exceptions, like the ability to invoke script from any origin 
in the context of one's own origin).

Cross-origin mechanisms work on the principle of code from one origin 
opting into communication with code from another origin, with 
communication only being possible if both sides opt in.

On Thu, 9 Apr 2009, Linner, David wrote:
>
> Looking into the hybi wiki and the use cases listed there (e.g. 
> collaborative editing, multiplayer games) I get the feeling state 
> synchronization is quite important. So, I think a shared memory 
> interaction model would be suitable for these use cases. Implementing 
> such an interaction model on top of bidirectional messaging between 
> browser and server is not a problem, but a realization as JavaScript 
> library would result in a significant loss of performance.

In practice JavaScript performance has improved by orders of magnitude in 
the recent past and shows every sign of continuing to be the focus of 
serious performance work, so I don't think that JavaScript libraries are 
likely to be a performance bottleneck in the future.

On Fri, 10 Apr 2009, Greg Wilkins wrote:
> 
> However, IF we are in the game of picking winners or designing new 
> protocols, we could do a lot worse than starting with a close inspection 
> of BEEP and the concerns that they address.

BEEP was amongst the many protocols that I examined closely when writing 
the WebSocket proposal.

> The standard HTTP security model would be used to establish a connection 
> and then the upgrade is unable to break out of that connection etc.

What is the standard HTTP security model? WebSocket wasn't able to use it, 
nor was XHR2; in both cases we had to add an extra layer to get cross- 
origin restrictions into HTTP. Are we missing something?

On Mon, 13 Apr 2009, Jonas Sicking wrote:
> 
> 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.

I've added an optional protocol ID to WebSocket, which is sent along with 
the handshake and (if present) must be present in the response back from 
the server.

On Tue, 14 Apr 2009, Jamie Lokier wrote:
> 
> 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.

Why would it be better for it to be a big bunch of new code in the 
browser, with perhaps only one web server and application backend, rather 
than a big bunch of new code in a JS library, with perhaps only one web 
server and application backend?

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

Writing an attractive web application with lots of updating documents and 
tiny widgets without using a large bit of Javascript seems optimistic.

On Wed, 15 Apr 2009, Greg Wilkins wrote:
> 
> 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!.

Well, it's their server. Maybe they don't mind.

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

IMHO, taking control away from the author like this isn't a good idea. 
Giving authors a shared worker and low-level sockets IMHO gives them much 
more flexibility than imposing a particular multiplexing design on them.

On Thu, 16 Apr 2009, Greg Wilkins wrote:
> 
> 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.

But the tools to fix the problem are available to the author. It's not a 
problem if the author can fix it. It's not like we're preventing authors 
from using multiplexed connections.

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

The difference is that the resource here is per-server anyway. Cooperative 
multitasking on a per-process level is a perfectly reasonable strategy 
(indeed it underlies "modern" techniques like fibers), it's only a problem 
when it is the mechanism used to share the CPU between different 
processes, where it allows one to take down another.

On Fri, 17 Apr 2009, Greg Wilkins wrote:
> 
> 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.

The introduction section is yet to be written, but will be in due course.

> Another problem is that the handshake is defined by explicitly saying 
> what bytes to send: [...] That's a really long winded way of saying send 
> a HTTP/1.1 request with some headers set.

There's a big difference, which is that the exact bytes matter, as the 
client will check that they are sent as described exactly.

> 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

Yes, it is indeed illegal as a WebSocket handshake. This is required 
because if we allowed any correct HTTP request/response that happened to 
have the right semantics, it would be significantly easier to smuggle 
messages to non-HTTP servers.

On Fri, 24 Apr 2009, Greg Wilkins wrote:
> 
> 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.

Why can't the 0x00 and 0x80 frames be used for this?

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

Why can't the existing API be wrapped by a library to offer this?

Generally speaking I am strongly against the idea of the Web platform APIs 
doing things for convenience rather than adding actual new features. As 
noted above, I think it is important for browsers to provide a core 
feature set but not to succomb to a feature creep where they provide all 
the features that authors will ever need.

Christopher Blizzard of Mozilla said it in the context of O3D recently:

   http://www.0xdeadbeef.com/weblog/?p=1223

I think his point applies very much here.

On Thu, 16 Apr 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> > I don't understand the relevance of HTTP to this discussion.
> 
> HTTP is our starting point.

TCP is my starting point.

> It is how our browsers initiate connections

HTTP is how browsers request resources. That this is layered on top of 
connections is IMHO mostly academic; HTTP isn't a connection protocol.

> It is the protocol that is most likely to get through firewalls

SSL seems even more likely to go through reliably.

> It is a brilliant example of how an extensible flexible protocol can
> adapt to changing usage.

It certainly has been extended a lot.

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

That's certainly one scenario that seems useful to support, yes.

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

Or we can tunnel it over SSL.

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

I don't see why WebSocket would be the only widely supported upgrade 
protocol. I do think each protocol should be considered, developed, and 
implemented on its own merits.

On Thu, 9 Apr 2009, Peter Saint-Andre wrote:
> > 
> > Sure, if you can use libraries then implementing any protocol is 
> > trivial. The point is that the protocol should be simple enough that 
> > one doesn't need to rely on libraries to get a compliant 
> > implementation.
> 
> Where does this requirement come from? I have never seen a similar 
> requirement in any RFC.

It comes from experience seeing all those RFCs get implemented in 
incredibly buggy ways over and over again.

> And are you assuming that developers should be able to implement this 
> protocol without any libraries whatsoever? Not even for TCP, UTF-8, or 
> anything else?

I wouldn't expect people to implement the UTF-8 layer themselves, though 
if they don't need to transfer user text (or if they just pass the user 
text unmodified to a database, or some such) then they wouldn't even need 
that. Both UTF-8 and TCP are core parts of most system APIs these days.

On Tue, 14 Apr 2009, Maciej Stachowiak wrote:
> 
> I think multiplexing multiple message streams, though it may seem useful 
> at the protocol level, is not a critical building block.

I agree; I think it is easily enough implemented as a layer on both sides 
(just prefix each message with a number giving the channel ID, and 
dispatch incoming messages to registered listeners based on ID).

On Tue, 14 Apr 2009, Greg Wilkins wrote:
> 
> implementing multiplexing is not the pain point as there are a million 
> ways to do it, ranging from trivial to amazingly complex.

Exactly. That's why we shouldn't bake one into the spec, IMHO.

> Websocket presents a nice simple interface that is easy for web developers
> to use directly.  So they will use it directly!

Why won't people use libraries on the client, as you argue they will to 
use WebSocket on the server?

> There is ZERO chance that all these diverse communities will come together
> and decide on how to share and multiplex connections.

Why is that a problem? We don't need everyone doing the same thing. We 
only need each site to be consistent within the site.

On Tue, 14 Apr 2009, Jamie Lokier wrote:
> 
> It's easy to write a simple HTTP server using a select() loop too, if 
> you know unix, or Perl, or Python.  There are lots of bad ones around to 
> prove it.  It's even easier with fork().

It's a lot more than 100 lines of code to write a compliant HTTP server 
in Perl.

On Thu, 16 Apr 2009, Greg Wilkins wrote:
> 
> I don't know if limiting connections on the server was a motivation for 
> the 2 connection limit, but as a developer of a HTTP server, I 
> appreciate the limit as every connection to the server consumes some 
> kernel resources and buffers.

The Web Socket protocol spec has been updated to clarify that there is no 
limit to the number of connections, but that user agents should never 
actually open more than one _new_ connection to the server at a time (so 
the most number of unexpected connections per client that a server can see 
is one).

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

---

From: Martin Tyler <[email-masked]>
Date: Fri, 24 Apr 2009 12:00:24 +0100

Hi folks, I've been on holiday for a few weeks so only just managed to read
up on this list.

> messages to non-HTTP servers.
I'm not sure I understand this smuggling of messages, could you explain?
Otherwise you seem to be saying the exact bytes matter without explaining
why.

It seems odd to me that the headers need to be exact.. One of the big
headaches I can see with WebSocket or anything like it is compatibility with
existing proxies, which is why this has to be some kind of HTTP (at least to
start with) rather than a TCP socket. HTTP proxies will sometimes parse
request/headers from the client and write their own when passing the message
on to the server.. won't requiring the exact bytes above cause problems
here?

A more general point about WebSocket and proxies. I don't know what
experience the people on this list have exactly, I am from Caplin Systems
(Liberator comet server amongst other things), most of our customers are
investment banks with large inflexible web architectures. At the start of
most projects we go through the same problem of explaining that Liberator
will work best if it is Internet facing.. most of these banks setups consist
of multiple tiers of proxies/webservers/appservers etc.. usually everything
sits behind a thin reverse proxy layer. Liberator (and most Comet servers I
would imagine) can work behind these, but you can lose out big time on
performance since the proxy isnt designed for the kind of traffic a comet
server might deliver.

Is this the same in other industry sectors?

Will WebSocket work behind a reverse proxy? It doesn't look like it to me,
the reverse proxy would have to understand WebSocket. I don't have a
solution for this, just wanted to make sure people were aware of it.

Another thing that seems to be a hot topic is this goal of 12 year olds
writing WebSocket servers. I can see why it should be simple for someone to
write a server side WebSocket component (like a CGI script), but writing the
whole server doesn't really seem that important. CGI scripts are run by
webservers, they aren't listening for requests themselves. Surely it would
be better to try and separately work on a new CGI/Servlet/Whatever interface
or guidelines for servers to support that works with WebSocket like
communication rather than thinking about 12 year olds writing the servers
themselves.

Another topic (sorry for not following up on specific posts) has been how
low level the protocol is, eg people want 'channel' like sematics and HTTP
style headers or meta data. I'm not sure where I stand on this, but we
should be careful when suggesting certain features that they are general
enough - we all have certain applications in mind, eg our own projects or
other things you might be considering - but any features should be
sufficiently general concepts that are genuinely useful. Personally I think
I would be fine with the message semantics as they currently stand, but I
can understand how many things could benefit from 'channels' and headers.

Regards
Martin

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 25 Apr 2009 00:13:44 +1000

Wow!

For someone who is advocating against multi-plexing support you have certainly
merged a lot of threads into one.

I think you're putting up a lot of straw men in your responses.  You've assumed
that because I'm highlighting the problem of sharing a channel that I'm advocating
a one-size-fits mandatory multiplexing solution.     I think there might be some
middle ground between those extremes.

You also can't argue that users should be able to not use libraries and
write their own websocket servers, then on the other hand say that libraries
are the answer to diverse communities spontaneously coordinating their
socket sharing solutions (says Greg - guilty of building his own straw man).

For more detailed comments, I'll try to demux your thread and respond to specific
points in the original threads

cheers

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 24 Apr 2009 16:01:11 +0100

Martin Tyler wrote:
> HTTP proxies will sometimes parse request/headers
> from the client and write their own when passing the message on to the server..
> won't requiring the exact bytes above cause problems here?

In fact HTTP proxies are _required_ to do this by the HTTP spec: they
must add a Via header.  Not all do.

Also, in practice, you need to be able to use proxy authentication
sometimes - there are several ways that is done.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 25 Apr 2009 01:47:05 +1000

> messages to non-HTTP servers.

Ian,

Surely a message that happens to have both correct syntax and semantics
is a correct and acceptable message!

The philosophy often associated IETF protocols is:
   "be strict in what you generate, but forgiving in what you accept."

The fact that html has not been displaced by xhtml is testament to
why such flexibility is required to achieve interoperable in
an imperfect world.

> Why can't the 0x00 and 0x80 frames be used for this?

I could equally say that since 0x80 packets can be be used to send
UTF-8 messages, then the 0x00 frame type is not needed.
An application could just assume the message contents are what is
expected.  Why have a frame type byte at all and both ends can
just assume the content and framing type!

Unfortunately such assumed solutions do result in robustness:
  + Clients and servers are not always implemented or upgraded
    simultaneously and sometime packets will be sent that the other
    end cannot understand.
  + Sometime specifications are interpreted differently
    interpretations can be implemented, which while semantically
    correct have slight variations in implementation.
  + Clients do connect to wrong ports.

Standardized metadata is a proven way that errors and differing
versions or interpretations can be handled, ignored or alarmed.

MIME encapsulation is the internet equivalent of the hydrogen atom
inscribed on the side of the voyager space probes.  It is a
lingua-franca on which diverse parties can base more complex and
diverse exchanges and protocols.

> feature set but not to succumb to a feature creep where they provide all 

Standardized meta data is not for convenience, but for robustness
and flexibility.

I think that rather than a limit frame-type byte, MIME encapsulation
should be the core feature of websocket.

But if a frame-type is to be a core feature of websocket, then
I'm proposing use of that core feature that will 2 of the
254 currently unused values.

Surely MIME encapsulation has already proven itself enough
to warrant such a small investment?

> SSL seems even more likely to go through reliably.

SSL is a hugely expensive resource for servers, often requiring
dedicated hardware.

While I'm generally supportive of innovative ways to re-use
existing technologies, I do think the cost of using SSL for
non secure traffic is likely to be prohibitive.

It strikes me as counter productive to byte squeeze a protocol
such that it can't be carried over HTTP, only to then force
SSL encryption.

> limit to the number of connections

Is there any analysis or evidence that this will not adversely affect
TCP/IP flow control or server scalability?

What are the reasons that drove the limitation of HTTP connections
that do not apply to websocket?

 > but that user agents should never

I'm not sure how this helps?

As a server implementer, I do not have any issue with the rate of new connections.
The problems that I have are with the resources allocated to the total
number of connections.

regards

---

From: Mario Balibrera <[email-masked]>
Date: Fri, 24 Apr 2009 11:35:10 -0700

GW wrote:

A Frank points out in an earlier post, the 2-connection limit was conceived
in large part to prevent a browser from crashing a sh*tty synchronous web
server with 10 image requests. No one would ever, ever, ever consider
deploying a persistent-connection app on something that fragile. Ever.

MT wrote:
Another thing that seems to be a hot topic is this goal of 12 year olds
writing WebSocket servers. I can see why it should be simple for someone to
write a server side WebSocket component (like a CGI script), but writing the
whole server doesn't really seem that important.

By the same token, if a 12 year old wants to write a CGI script, she should
use existing tools that exist for that precise reason. Neither WebSocket nor
any of the protocols we're discussing here are even in the same ballpark.

Really, the 12 year old would most likely not write a WebSocket server,
because proxies and WS readers and so forth would (and do) exist. The kid
wouldn't have to implement anything resembling a server. At the most basic
level, it would be a matter of writing an onread function that parses some
plain text. Could it be any more hello world? (I realize this is basically
what you're saying, Martin. I'm just mad that CGI keeps coming up.)

Mario Balibrera

On Fri, Apr 24, 2009 at 8:47 AM, Greg Wilkins <[email-masked]> wrote:

>>> 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.
>>>
>>
>> noted above, I think it is important for browsers to provide a core feature
>> set but not to succumb to a feature creep where they provide all the
>> features that authors will ever need.
>>
>
>>> the 2 connection limit, but as a developer of a HTTP server, I appreciate
>>> the limit as every connection to the server consumes some kernel resources
>>> and buffers.
>>>
>>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Ian Hickson <[email-masked]>
Date: Fri, 24 Apr 2009 20:09:03 +0000 (UTC)

On Sat, 25 Apr 2009, Greg Wilkins wrote:
> > Yes, it is indeed illegal as a WebSocket handshake. This is required because
> > if we allowed any correct HTTP request/response that happened to have the
> > right semantics, it would be significantly easier to smuggle messages to
> > non-HTTP servers.
> 

The problem is that if we are flexible with the handshake, then we can 
much more easily end up finding ourselves accepting a connection from a 
host that has been tricked into sending something that looks like a 
handshake but is in fact just the normal operation of another protocol. 
One of the requirements is that we be as sure as possible that the target 
host is truly willing to opt into communication with the script's origin.

> UTF-8 messages, then the 0x00 frame type is not needed.

Indeed, people have argued that. The reasons for having both of these have 
been discussed before on this list, but they boil down to th need for 
distinct APIs for binary and text data requiring different frame types, 
and a concern over implementations not being able to accurately measure 
UTF-8 but errors in measuring UTF-8 being difficult to detect.

> expected.  Why have a frame type byte at all and both ends can just 
> assume the content and framing type!

That would be ideal, yes. The protocol is (IMHO) about as close as we can 
get to that right now.

>    simultaneously and sometime packets will be sent that the other

The protocol is designed with this in mind (in fact as currently designed, 
you'll notice that the client-side supports length-delimited binary 
packets, for future compatibility, but the server side doesn't, since it 
knows what types of packets it needs to support).

>    correct have slight variations in implementation.

As far as I can tell, there is no ambiguity allowing for different legal 
interpretations in this case. (This is why the spec uses step-by-step 
algorithms with clear conformance criteria, instead of a narrative and 
constraint-based definition.) If you find a way in which the spec is 
ambiguous, please let me know.

>  + Clients do connect to wrong ports.

This is one reason we have the handshake and why it is so strict.

> Standardized metadata is a proven way that errors and differing versions 
> or interpretations can be handled, ignored or alarmed.

It's _a_ way, indeed. IMHO not a particularly successful one, for example 
look at the many ways in which HTTP status codes are ignored (e.g. <img> 
pointing to a 404 image is treated like a 200).

> inscribed on the side of the voyager space probes. It is a lingua-franca 
> on which diverse parties can base more complex and diverse exchanges and 
> protocols.

MIME is a way to transfer resources. WebSocket isn't about resources. If 
you want to transfer resources, use something like HTTP.

> > Generally speaking I am strongly against the idea of the Web platform 
> > APIs doing things for convenience rather than adding actual new 
> > features. As noted above, I think it is important for browsers to 
> > provide a core feature set but not to succumb to a feature creep where 
> > they provide all the features that authors will ever need.
> 
> Standardized meta data is not for convenience, but for robustness and 
> flexibility.

It's trivial to include metadata in text packets, and it can be done in 
whatever way is most convenient for the type of data being sent. If a 
simple code is more effective, that can be done. If each message needs a 
URL and EXIF data transfered as an RDF block, that can be done. If 
MIME-like headers are best, that can be done.

> Surely MIME encapsulation has already proven itself enough to warrant 
> such a small investment?

It has proven itself to be adequate (though by no means outstanding, IMHO) 
for labeling resources. And it is quite possible to use MIME encapsulation 
in a WebSocket subprotocol if that is desired. But why force it on 
everyone? It's certainly not the be-all and end-all of metadata labeling, 
and it isn't a feature everyone needs.

> > > I don't know if limiting connections on the server was a motivation 
> > > for the 2 connection limit, but as a developer of a HTTP server, I 
> > The Web Socket protocol spec has been updated to clarify that there is 
> > no limit to the number of connections
> 

No. If anyone is able to do such an analysis, I'd be very interested in 
seeing the results. It should be noted though that load on the server 
itself isn't a concern, since the author is the one starting the 
connections and he can quite easily just multiplex everything using a 
shared worker if so desired. Only the impact on the client and the network 
are realy a concern.

> What are the reasons that drove the limitation of HTTP connections that 
> do not apply to websocket?

The reasons that drove the limitation of HTTP connections -- the ability 
for untrusted third-party content to overload a server with many 
connections -- DO apply to WebSocket, and WebSocket has been limited to 
prevent such abuse (even more so than HTTP; WebSocket only allows one 
pending non-established connection at a time).

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 24 Apr 2009 22:13:14 +0100

> That would be ideal, yes. The protocol is (IMHO) about as close as we can 

Can you say a bit about why that isn't possible?

I asked myself the same thing a while ago: since every application has
to know the format of what it's going to receive _anyway_, in
considerable byte/character-level detail, and application-defined
sub-framing metadata (such as it's own sequence numbers, target object
ids or whatever), what is the purpose of the framing byte?

Why is it not enough for the receiving API to offer
receiveBinaryFixed(length), receiveBinaryFrame() and
receiveTextUTF8Frame() methods?

If it's just to catch a class of errors, where what was sent didn't
match the expected format, why is it limited to just the two types?

> knows what types of packets it needs to support).

That's interesting.  If the protocol reaches mainstream browsers, I
imagine using the length-delimited binary packets if they work.

It will be a shame if it's "specified" but half the client
implementations are broken because that part was never tested.  I'd
have to have to encode binary data into UTF-8 *and then decode UTF-8
back into binary in Javascript* just to make it work on real
deployments. :-)

> This is one reason we have the handshake and why it is so strict.

It sounds like the reason could be explained more clearly in the
document, as the question shouldn't have come up.

I'm a bit concerned if it's so strict that proxies (including
transparent ones) will break it though.

> pointing to a 404 image is treated like a 200).

Eh?  Is it?  I've always seen a broken image icon, I'm pretty sure.

> you want to transfer resources, use something like HTTP.

WebSocket is about messages.  HTTP (as a protocol, not a data model)
is about messages with some metadata and a request-response model.
I'm not seeing that much difference.

I understand that WebSockets needs to be simpler, but I do thing the
"not about resources" argument is spurious.  Of coures we will
transfer small HTTP-style resource messages over WebSockets.  I
foresee that being a major use of it.  Even if it ends up looking like
a Bayeux-style JSON frame in practice.

> MIME-like headers are best, that can be done.

What do you recommend for a binary blob with metadata?  Two frames,
one for text metadata and one binary?

> and it isn't a feature everyone needs.

Given that, I'm still wondering why we're looking at a WebSocket
message framing that isn't a feature everyone needs.  Why doesn't it
go the connection handshake then provide a TCP stream?  The message
framing doesn't even provide anything useful that fits with future
transport protocols such as SCTP.

> shared worker if so desired. Only the impact on the client and the network 

Without a doubt, you get better end-to-end TCP/IP with fewer
connections provided both ends are consuming all the data sent to
them, both ends are multiplexing different message sources fairly, and
they have similar QoS requirements.  It's a simple matter of coherence
vs. incoherence in the packet stream, and of small messages batching
into larger packets.  Batching also means better throughput.

But we should be looking beyond TCP/IP, and into what SCTP/IP
provides.  If not now, then anticipating how to map onto it in future.
SCTP's main feature is the ability to have separate message streams
multiplexed over a single aggregated packet stream, handled properly
at the transport level - avoiding many of the problems with that over TCP.

> pending non-established connection at a time).

I suspect that limitation will have to be ignored in practice.

If you have a web page with many active parts authored by different
people, and a connection setup round-trip time of 2 seconds (but you
could do 100 in parallel), you simply will not be happy when the page
takes 1 minute for all of it to appear.

-- Jamie

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 24 Apr 2009 14:42:52 -0700

> pending non-established connection at a time).

Umm, that's very creative history.

FTR, the limitation exists because of social engineering at the IETF.
Netscape introduced four parallel connections in late 1994.  It was
observed that the TCP overhead from four simultaneous connection
initializations, followed by often-aborted requests for images, were
causing the cross-Atlantic network links to become congested, and
Netscape's own servers were encountering TCP connection-queue limits.
Therefore, keep-alive and persistent connections were added to HTTP.

However, browser developers are notoriously user-centric (i.e.,  
selfish).
Instead of reducing the number of keep-alive connections, they deployed
four parallel long-lived connections in spite of the fact that two
connections performed better over congested or slow links.  Since that
behavior was considered harmful to the global commons of TCP, the
HTTP WG added a social requirement that no more than 2 persistent
connections be used to the same host.

All of the significant HTTP servers had internal connection
management of some form (hunt group, server pool, event-based, etc.)
by mid 1995, long before keep-alive and persistent connections existed.
Flash-crowds were a problem even before Navigator was released.

I don't know if the connection limit is still necessary.
My guess, judging from the amount poured into sites like hulu that
transmit HD over the net, is that the connection limit is no longer
needed by the backbone carriers.  Websites certainly don't care.

....Roy

---

From: Ian Hickson <[email-masked]>
Date: Fri, 24 Apr 2009 21:49:18 +0000 (UTC)

> ids or whatever), what is the purpose of the framing byte?

The DOM Events model is a push mechanism, so to get predictable 
interoperable behaviour, we have to have a way of defining the end of a 
block of content (either by length declaration or by a sentinel byte).

Right now we can only support Unicode data, as JS doesn't have binary data 
support yet, so on the short term we need a way to transfer text. On the 
longer term we need to be able to extend this to support binary data. Thus 
the two kinds of data. We use different framing for both because it is 
easier to support strings using a termination byte than a length 
declaration (measuring UTF-8 data is easy to get wrong in undetected ways, 
especially when testing only with ASCII), but it is easier to support 
length declarations than sentinels for binary data.

> receiveTextUTF8Frame() methods?

It doesn't really fit the DOM model.

> > The protocol is designed with this in mind (in fact as currently 
> > designed, you'll notice that the client-side supports length-delimited 
> > binary packets, for future compatibility, but the server side doesn't, 
> > since it knows what types of packets it needs to support).
> 
> implementations are broken because that part was never tested.  I'd have 
> to have to encode binary data into UTF-8 *and then decode UTF-8 back 
> into binary in Javascript* just to make it work on real deployments. :-)

Browsers don't currently support binary data at the JS level. Once they 
do, we'll add the binary support to the API.

> document, as the question shouldn't have come up.

Yeah, I've yet to write the intro section.

> transparent ones) will break it though.

It would be useful to do some research to see whether there are specific 
ways in which we can relax the handshake to allow for proxies, without 
substantially opening up the attack surface.

> Eh?  Is it?  I've always seen a broken image icon, I'm pretty sure.

Not if the 404 response is an image.

> WebSocket is about messages.  HTTP (as a protocol, not a data model) is 
> about messages with some metadata and a request-response model. I'm not 
> seeing that much difference.

While there may be superficial similarities, I think one has to practice 
architectural astronautics to get the HTTP and WebSocket models to appear 
similar. It's like saying SMTP and FTP are the both "about messages".

> > It's trivial to include metadata in text packets, and it can be done 
> > in whatever way is most convenient for the type of data being sent. If 
> > a simple code is more effective, that can be done. If each message 
> > needs a URL and EXIF data transfered as an RDF block, that can be 
> > done. If MIME-like headers are best, that can be done.
> 
> What do you recommend for a binary blob with metadata?  Two frames, one 
> for text metadata and one binary?

Once we have binary data in JS, we will presumably also have a library of 
functions to convert text to binary and vice versa, so it would be simpler 
to just put the headers before the blob, as Greg suggested.

> > The reasons that drove the limitation of HTTP connections -- the 
> > ability for untrusted third-party content to overload a server with 
> > many connections -- DO apply to WebSocket, and WebSocket has been 
> > limited to prevent such abuse (even more so than HTTP; WebSocket only 
> > allows one pending non-established connection at a time).
> 

That's a good thing, it will encourage multiplexing.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 25 Apr 2009 09:24:43 +1000

> receiveTextUTF8Frame() methods?

Indeed!

If websocket limited itself to being a minimal data framing protocol,
then it could be well suited to be the standard adopted by
firewalls,gateways and proxies to support upgraded HTTP connections.

But web socket also is providing support for a very specific
application - DOM based applications written in javascript
running withing a browser and communicating via untyped UTF-8
text datagrams.

Now this specific application may be suitable for a large
number of uses, but it is certainly not suitable for all.

Thus those that want to write by directional protocols using
a different base message type (eg gzipped utf-8 text
datagrams or arbitrary MIME encapsulated resources) are going
to ask - "why do a specific class of javascript DOM users get
favour favoured-son status?" and "why can't my packet type be
supported?"

Ian obviously feels that he does not want to require compliant
implementations to have to have support for MIME encapsulation
I assume because he can see a class of application that can be
written without it.   I likewise don't want to have my compliant
implementation support sentinel framed UTF-8 strings when the
class of protocol/application that I want to write would not
use such a limiting datagram.

It would seam that support for UTF-8 text datagrams has opened
indeed created the feature creep demand that Ian has previously
alluded to.   This is because by supporting 2 framing types,
websocket violates the 0, 1 or infinity principal and there
is demand for the infinity option.

It would be far better if websocket restricted itself to
1 or provided a standardized way to negotiate the infinite.

regards

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 25 Apr 2009 02:01:10 +0100

> block of content (either by length declaration or by a sentinel byte).

That makes no sense.

If I call ws.getTextUTF8Frame() then of course you can read a UTF-8
sentinel-terminated string and send me the event when it's done.

If I call ws.getBinary(1024) then you receive 1024 bytes and send me
the event when that much is received.

Nothing about "push mechanism" or DOM Events requires the base
protocol to have framing.

> the two kinds of data.

Fine, I accept the need for a text option for Javascript compatibility.

(But I've got a horrible feeling non-JS client apps are going to be
sending binary packets encoded with gzip and then transcoded into a
UTF-8 compatible octet sequence to run over JS-compatible infrastructure.)

> We use different framing for both because it is 

But you haven't given a good reason why the protocol has to be
self-describing in that way (with a frame type byte).  The app can say
what it's expecting, and you can read the framing the app asks for.
It's easy to use, and efficient.

That's what all other programming languages do when reading from sockets!

> It doesn't really fit the DOM model.

I think (forget..) the DOM model for XmlHttpRequest is that you get an
event telling you something has happened, then you read whatever state
is available from the XHR object.

If WebSockets did the same, you'd get an event when data is available
to read, then you'd read as much as you can with those functions until
you got an error saying "not enough available", then you'd get another
event when more data is available.

That sounds both simpler to use in Javascript and more efficient with
rapid streams of small messages than an event per message.

> substantially opening up the attack surface.

One way that's very likely to work is over SSL.

Another is to embed the stream inside a pair of streaming HTTP
requests, as AJAX/Comet apps do.  Another is to use long-GET, for
maximum compatibility.

If you embed in a way which sufficiently advanced proxies are
officially allowed to "unembed", you can be compatible with existing
infrastructure at the same time as allowing an upgrade path to getting
rid of the embedding.  (That's what I'm looking at for bidirectional
multiplexed cached HTTP over existing infrastructure).

That's all very ugly, I know.  But very compatible, in a way that I'm
not convinced the WebSockets handshake will be for practical
internet-sized deployments.

> similar. It's like saying SMTP and FTP are the both "about messages".

Can't entirely disagree :-)

> That's a good thing, it will encourage multiplexing.

If multiplexing is good, why aren't we making it the trivial default option?

I.e. if there was an API which does multiplexing by default, but where
you could ask for a dedicated connection easily and get identical
behaviour except over a dedicated connection - wouldn't that encourage
multiplexing even better than non-obvious networking characteristics?

You must have noticed that most web developers don't know much about
network performance and aggregate behaviour beyond keeping the size of
pages small enough for some target audience, and which browsers to test.

I'm not saying we should optimise everything or bake in lots of
complexity.  I like that WebSockets aims for simplicity.

But if it were as trivial as a flag to the WS constructor meaning
"give me a multiplexed connection" vs. "give me a dedicated
connection", that would go a long way to improving overall system
behaviour in the presence of millions of web developers who don't know
much about networking, I suspect.

I know that's an unproven data point, and would need measurements
before committing to it, but please at least consider the possibility,
then we can talk about what it would look like in detail.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 25 Apr 2009 02:19:51 +0100

Roy T. Fielding wrote:
> they deployed

That right there points at a reason to be cautious, at least, about
numbers of connections over congested or slow links.

I'll add that the "many connections but maximum one outstanding new
connection" rule from WebSockets will behave poorly with high latency
links in addition to congested and slow ones.

Quite simply, many connections to the same site is poor use of TCP.
This might not be obvious to anyone who sees TCP as a simple byte
pipe, and isn't aware of what TCP has to do with packets and what
makes TCP perform better or worse.

If a site works well over high-speed broadband with just one user, and
sucks over dialup, that's not our problem.

But web app developers can't be expected to know the finer points of
transport protocol behaviour.  As infrastructure engineers we can make
sites suck more, or less, by our choices at that level.

> needed by the backbone carriers.  Websites certainly don't care.

I think you're right about the backbone.

Large numbers of long-lived (long-GET) connections are a problem for
load-balancing reverse proxies at not-so-high-profile web sites,
according to another posting about Comet deployment.

I've seen quite a lot of posts around the net about how Comet
(i.e. long-GET or streaming-GET) is very bad for web servers, and
cannot ever be as efficient as polling every few seconds with Ajax
requests.

Of course this is nonsense to anyone with half a computer science
degree, but the belief seems to come from a lot of server-side
infrastructure spawning threads, processes and other expensive things
per connection.

At the client end, those slow or congested links are still quite common,
and multiple computers congesting a shared home link are getting more
common (I suspect).

-- Jamie

---

From: Ian Hickson <[email-masked]>
Date: Sat, 25 Apr 2009 01:22:53 +0000 (UTC)

On Sat, 25 Apr 2009, Jamie Lokier wrote:
> If I call ws.getBinary(1024) then you receive 1024 bytes and send me the 
> event when that much is received.
> 
> Nothing about "push mechanism" or DOM Events requires the base protocol 
> to have framing.

I guess I don't understand what you're proposing. Could you describe your 
proposal in more detail?

> UTF-8 compatible octet sequence to run over JS-compatible 

Non-JS client apps would presumably not use WebSocket. The whole point of 
WebSocket is to provide something optimised for Web apps only. A native IM 
client, for example, would just use XMPP.

> > It would be useful to do some research to see whether there are 
> > specific ways in which we can relax the handshake to allow for 
> > proxies, without substantially opening up the attack surface.
> 

Indeed.

> Another is to embed the stream inside a pair of streaming HTTP requests, 
> as AJAX/Comet apps do.  Another is to use long-GET, for maximum 
> compatibility.

Those techniques are already possible, and WebSocket isn't attempting to 
remove that. The idea if just to provide another option that uses just a 
single TCP connection ("TCP for the Web").

> > > could do 100 in parallel), you simply will not be happy when the 
> > > page takes 1 minute for all of it to appear.
> >

Generally speaking I am strongly against the idea of the Web platform APIs 
doing things for convenience rather than adding actual new features. As 
noted in earlier e-mails, I think it is important for browsers to provide 
a core feature set but not to succomb to a feature creep where they 
provide all the features that authors will ever need.

> behaviour except over a dedicated connection

I would be interested in seeing a concrete proposal. My impression is that 
this would be a non-trivial addition to the core protocol and API, and so 
I would prefer to not add it to the core building blocks.

> - wouldn't that encourage multiplexing even better than non-obvious 
> networking characteristics?

One minute of latency is pretty obvious.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sat, 25 Apr 2009 20:26:50 +0200

> That's what all other programming languages do when reading from sockets!

In that case, do we even need a new protocol?

- Sylvain

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 27 Apr 2009 00:11:49 +1000

Ian Hickson wrote:

> Non-JS client apps would presumably not use WebSocket. 

Why?

It seams really strange to propose an IETF protocol that
is so heavily  influenced by one programming language used
in one particular application.

 > The whole point of WebSocket is to provide something optimised
 > for Web apps only.

Which is why it might not be a protocol that all can get behind and
give it the support that it needs to be accepted as a standard and
then implemented widely.

 > A native IM  client, for example, would just use XMPP.

A native IM client still has the problem of tunneling through
firewalls, proxies and gateways.   Thus they have to tunnel
XMPP over BOSH, which uses all the long polling techniques
over HTTP.

I'm sure XMPP client developers would prefer to replace BOSH
with an HTTP upgrade protocol designed for bidirection usage over
a single socket that can legally tunnel through firewalls.
If the don't, that implies that HTTP is sufficient for there
needs thus it is also likely that it is sufficient for web
applications.

Indeed, cometd/bayeux is moderately happy with long polling
over HTTP and websocket as it is currently formulated
does little or nothing to address the issues that we have.

But websocket is very close to something that could help
and could be made more widely applicable with some small
changes.

I really think those that are proposing websocket should
consider widening the scope of the proposal that it includes
the interests and concerns that have been expressed on this list.

It might be perfectly suited to the webapplications that some
want to write, but unless it can attract support from a wider
audience I doubt that will receive the support it needs to
be adopted.

regards

---

From: Ian Hickson <[email-masked]>
Date: Sun, 26 Apr 2009 18:01:17 +0000 (UTC)

> > Non-JS client apps would presumably not use WebSocket.

Because the whole point is to provide a protocol that is safe for Web 
pages. If you have native access to TCP, I don't see any reason why you'd 
using WebSocket instead of just using a more appropriate protocol or using 
a custom protocol over TCP. The security aspects of WebSocket make no 
sense in a situation where the program has control over the connection.

> It seams really strange to propose an IETF protocol that is so heavily 
> influenced by one programming language used in one particular 
> application.

I agree. This wasn't originally going to be proposed to the IETF, it was 
just a subsection of the WebSocket API as part of HTML5. The IETF 
requested that it be split out into a dedicated RFC. If this group doesn't 
think we should develop the protocol separate from the API, I'm happy to 
move them back into the same document. What is the group's opinion?

> But websocket is very close to something that could help and could be 
> made more widely applicable with some small changes.

IMHO it doesn't make sense to try to abstract things out to solve two 
completely unrelated use cases (native IM apps and a protocol for JS 
running in browsers). I think it would be much better for dedicated 
solutions to be designed for each case. Trying to design abstract 
protocols that apply to unrelated use cases usually results in compromises 
that don't work well for any of the supposed use cases.

Having said that, I have no objection to us developing a generic protocol 
for tunneling other protocols over HTTP or upgrading from HTTP to other 
protocols, separate from WebSocket. Is anyone interested in editing such a 
specification? If so, I say we go for it.

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 26 Apr 2009 20:38:32 +0100

> sense in a situation where the program has control over the connection.

Once there is substantial deployment, the reason you'll see WebSocket
clients in other languages is that will be the only way to access some
web-based services that you don't control.

> move them back into the same document. What is the group's opinion?

I can't speak for the group.  My opinion is the wire protocol should
be kept very separate from the Javascript API for talking it.

The API should be designed entirely around whatever works best in
Javascript: be simple and easy to use for Javascript programmers.
If it's good, the API will survive a few changes of wire protocol.

And the wire protocol should take note of input from network engineers ;-)

> specification? If so, I say we go for it.

There are a number of ways, as many here know, to tunnel one-way and
two-way messages over HTTP.  Some are more reliable than others.  Some
work over HTTP protocol, but poorly or not at all over realistic
infrastructure.

I do think it would be good to put the known (useful) methods of
tunnelling into a concise, RFC-style document, and from there propose
best-practice methods for tunnelling over the existing and future web.

WebSockets could reference that, and WebSockets itself could be
standardised and implemented while the tunnelling strategy continues
to be refined based on real experience.  The WebSockets wire protocol
need not change, but strategies for tunnelling it might need to.

So count me as voting for separate documents on:

    - Javascript API for WebSockets
    - WebSockets wire protocol
    - Generic two-way message/stream tunnelling over HTTP

Each can remain small and focused on its domain.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 26 Apr 2009 20:47:01 +0100

> In that case, do we even need a new protocol?

No we don't while it's running.  TCP would be fine from this
perspective, and (imho) preferable as you could use it more easily
with any TCP services, just relaying after the connection setup.

But there are issues with security, service addressing, and operating
over port 80 (http) though, which WebSockets deals with in the
connection setup.  Those may be important for web pages establishing
sockets.

Flash in web pages can use plain TCP.  I'm not sure what the
restrictions are.

WebSockets uses port 80 to work over real infrastructure where other
ports may be firewalled, but unfortunately I suspect the "Upgrade:"
header isn't adequate for a significant minority of real
infrastructure in the way, nor the 101 response.  It's hard to know
without real measurements...  (Has anyone done such measurements?)

-- Jamie

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sun, 26 Apr 2009 22:57:08 +0200

> connection setup.  Those may be important for web pages establishing
Right, so I second you when you suggest we should clearly separate the 
transport protocol from the application's level one and indeed maybe 
from the transport protocol's perspective, all WebSockets has to define 
is the security measure to take to secure a connection and once it's 
done, let a socket be just that, a socket.

In other words, why do we need the framing part of the protocol? Ian?

- Sylvain

---

From: Ian Hickson <[email-masked]>
Date: Sun, 26 Apr 2009 21:05:21 +0000 (UTC)

> In other words, why do we need the framing part of the protocol? Ian?

Do these e-mails answer your question?:

   http://www.ietf.org/mail-archive/web/hybi/current/msg00248.html
   http://www.ietf.org/mail-archive/web/hybi/current/msg00252.html

I'm open to other mechanisms, but it's not clear to me what they would be. 
Concrete API proposals would be good here.

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 26 Apr 2009 22:13:22 +0100

> In other words, why do we need the framing part of the protocol? Ian?

As far as I can tell, the current WebSockets Javascript/DOM API
requires the protocol to have self-describing frames, because that's
how it knows when a message is received, then it delivers the message.

So it's a property of the API requiring that from the protocol.

Fine, if it really does make the API work better.  But as I said
earlier, there are other approaches to the API which still work with
the DOM "push mechanism" and don't have the protocol framing
requirement, and will then work with general TCP services more easily.

To be honest I do think framing is a good idea - splitting bytes in
Javascript would be messy (it doesn't have byte arrays) and message
frames is useful.  But I don't see the point of the type byte except
for the "future extension" of byte frames in Javascript.  All the
_real_ type information has to be application defined inside each frame.

So if you're going to have a future extension which is not to be
implemented in the first version and so cannot be used except when
explicitly requested, you might as well make it more general - plan
for accepting any byte stream, when/if byte handling is added to
Javascript.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 26 Apr 2009 22:14:07 +0100

> Concrete API proposals would be good here.

I agree they'd help a lot, and I'll take a go at it when I have time,
in a few days.

-- Jamie

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sun, 26 Apr 2009 23:47:57 +0200

> Concrete API proposals would be good here.
Well they triggered my question in fact (as per Jamie's emails too). If 
I recap, as I understand it, there's been a requirement to describe and 
define the best solution for long lived connections from browsers. That 
requirement has two main constraints and a feature.

The first constraint is to have a web oriented security model.
The second constraint is to be able to re-use the existing web 
infrastructure hence the HTTP bootstrap.

The feature is to allow for an API that plays well with both DOM and 
Javascript.

There are currently two drafts that deal each with one side of the 
overall problem at hand. One at the transport level describing the 
bootstrap mechanism and how to frame data. Another one at the browser 
level explaining how to consume and produce data frames.

I'm still wondering then why not keeping the bootstrap mechanism to 
preserve the security policy but strip out the framing part and redesign 
the Javascript API so that it acts like any other socket library in any 
existing programming language? In other words, let developers directly 
create Javascripts API that implement any given protocol.

You mentioned the push aspect of the DOM event model as well as the fact 
Javascript currently doesn't have binary support yet. I think it's 
taking the problem the wrong way, "we want to have this JS API because 
it fits us well so we need a protocol that maps to that API". Why not 
saying instead, "now that we have a secured connection, let's create a 
Javascript socket API and let developers play with it". I can't offer 
better API than:

open()
read(size)
write(data)
close()

Maybe Javascript lacks some aspects of other modern languages like 
binary support, is that rationale enough for creating a new framing 
protocol?

- Sylvain

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 27 Apr 2009 00:02:28 +0200

> I can't offer better API than:
>
> open()
> read(size)
> write(data)
> close()

Just to clarify:

open() would establish the secure connection using the HTTP bootstrap 
mechanism.

Then, as a developer, I shouldn't need the framing protocol described 
because I already  know what I'm expecting. I'm not opening a connection 
without knowing in advance what will be sent though. Once I have read 
whatever amount of data I need I would create a DOM event and push it 
through. I don't feel like I need the framing overhead to do that.

Now if my connection is used to transport several distinct protocols, 
that is different, but as Roy suggested, is there still a need to limit 
the number of connections opened by the browser these days? Do we need 
multiplexing?

- Sylvain

---

From: Ian Hickson <[email-masked]>
Date: Sun, 26 Apr 2009 22:58:50 +0000 (UTC)

On Sun, 26 Apr 2009, Jamie Lokier wrote:
> 
> As far as I can tell, the current WebSockets Javascript/DOM API requires 
> the protocol to have self-describing frames, because that's how it knows 
> when a message is received, then it delivers the message.
> 

Right.

> earlier, there are other approaches to the API which still work with the 
> DOM "push mechanism" and don't have the protocol framing requirement, 
> and will then work with general TCP services more easily.

> I agree they'd help a lot, and I'll take a go at it when I have time, in 
> a few days.

I look forward to seeing concrete proposals for how this would work.

> [...] I don't see the point of the type byte except for the "future 
> extension" of byte frames in Javascript.

That's the only reason for the type byte, yes.

> explicitly requested, you might as well make it more general - plan for 
> accepting any byte stream, when/if byte handling is added to Javascript.

I'm not really sure I see a way to do that. Concrete proposals would be 
very useful here.

On Sun, 26 Apr 2009, Sylvain Hellegouarch wrote:
>
> If I recap, as I understand it, there's been a requirement to describe 
> and define the best solution for long lived connections from browsers. 
> That requirement has two main constraints and a feature.
> 

The requirements that brought about WebSocket are a little more elaborate; 
they are documented here:

   http://www.ietf.org/mail-archive/web/hybi/current/msg00007.html

> I can't offer better API than:

Could you elaborate on the semantics of the read() and write() methods? 
e.g. do they block, how does the user know when to call them, what do they 
return, how does the user handle TCP packets that split UTF-8 bytes, etc.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 27 Apr 2009 10:01:25 +1000

> how it knows when a message is received, then it delivers the message.

What I think is also an unstated reason for having framing is that it
can be used to limit/define the buffering done by any intermediary (proxy/
gateway/firewall).

The minimal behaviour for intermediaries will need to be specified and
while it could be done in terms of immediate forwarding of every byte
received, that would significantly reduce the options for implementing
an intermediary and handling differing MTU sizes etc.

It would be more reasonable minimum requirement that an intermediary
must forward only when a complete frame is received.

Of course this would not prevent an implementation that did forward
every byte and/or packet received, as that would also meet this
minimum requirement.

regards

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 27 Apr 2009 02:08:53 +0100

> can be used to limit/define the buffering done by any intermediary (proxy/

It can, but is there anything gained by that?

It doesn't limit the buffering: I can send a 100MB frame - why not?
Will that break some intermediaries?  Am I out of spec sending that
from a server/client?  Does the spec give a maximum frame length,
which all frame-buffering intermediaries guarantee to support, and
will applications then need to work around that if they happen to have
a message which is larger?

Sending a large chunk of HTML to replace in a page is a likely use
case; you know how big those get.

My point is it's hard enough testing things on servers and clients.
Whatever deployed intermediaries there are, it's much harder for
specific web site authors to test against them, or even know what they
are.

So it's really important that intermediaries don't behave in strange
ways with arbitrary limits, especially if those limits cannot be
tested for and negotiated around easily later.

> an intermediary and handling differing MTU sizes etc.

TCP/IP provides pure byte streams without any boundaries.  There's no
connection between WebSockets frame boundaries and packet boundaries,
except by chance some of the time.

Intermediaries forward between TCP byte streams.  They only see byte
streams.  They can _parse_ the byte stream to get WebSockets frames,
but that has no connection with MTU which is an IP packet concept
below TCP, and hidden completely from intermediary applications.

Differing MTU is handled by the two TCPs.

Did you have something in mind where an intermediary bypasses TCP and
operates on IP packets directly?  (That would be quite different from
what's been proposed).

> must forward only when a complete frame is received.

It's very important that this is not misunderstood as _requiring_ an
intermediary to buffer a frame until it's received.  That would be
tragic :-)

I'm not sure what benefit it brings, if the protocol isn't
multiplexing different connections.

For an intermediary to be _allowed_ to delay data until a whole frame
is parsed limits how the protocol may be used.

The most stringent is that you can't use frame types that any
intermediary doesn't recognise, because it'll break their parsing.

Since only UTF-8 sentinel-delimited text frames will actually be
deployed at first, that means the first generation of intermediaries
will _only_ be able to forward that, if they take up your
implementation advice.

Should the spec say what happens when an intermediary cannot parse the
byte stream because it has an unrecognised frame type?  Is it
something newer clients/servers will be able to detect and workaround
(e.g. by tunnelling other frame types into UTF-8 encoded frames), or
will newer clients/servers have difficulty detecting and working
around older intermediaries which cannot handle other frame types?

By the way, this is quite different from HTTP chunking in an
interesting way.  HTTP chunk boundaries are parsed by intermediaries
for the useful ability to _change_ the boundaries to match
transmission characteristics.  Now _that's_ a usefully relaxed framing
constraint :-)

But that's not allowed in WebSockets because the boundaries are
part of the data transmitted.

I think a most reasonable requirement is:

   - Intermediaries don't edit the byte stream (unless they have
     specific reason to do so perhaps).
   - Intermediaries forward all of it in a reasonable time without
     attempting to buffer whole frames, which they might fail to do.

That will ensure intermediaries work with any frame size, and work
with any frame types (or length formats) which are added later to
clients and servers.

Now if multiplexing of any kind is added :-)  I'd still keep the
requirement to not attempt to buffer whole frames, for the same
reasons, but of course parsing and editing of some kind is implied.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 27 Apr 2009 22:46:25 +1000

> It doesn't limit the buffering: I can send a 100MB frame - why not?

Jamie,

I wasn't proposing that intermediaries MUST buffer whole frames.
I'm proposing that intermediaries MUST NOT buffer beyond a frame boundary.
ie the end of a frame must always trigger a flush of any buffers that
may or may not exist.

This is specifically different to HTTP chunking which is point to point
and an intermediary is perfectly entitled to buffer up all chunks before
forwarding an unchunked message.

>      attempting to buffer whole frames, which they might fail to do.

Something like would also work.  However it might be harder to
rigorously define "all of it in a reasonable time".   It might also
discourage some reasonable amount of buffering.

> requirement to not attempt to buffer whole frames

Agreed.

Indeed multiplexing might require transport level chunking of application
defined frames, so that large content does not delay other channels.

The trick is to find a way to support such complexity in a way that
still allows a fallback to simplicity if the complex features are
not required.

cheers

---

From: Martin Tyler <[email-masked]>
Date: Mon, 27 Apr 2009 14:37:15 +0100

Hi

I don't have any links or anything.

A reverse proxy basically pretends to be the actual server (as far as any
client or client proxy is concerned), but it passes on the request to the
actual server that is usually sitting behind another layer of firewalls.

Any polling or long polling comet solution should be fine with this, as will
most streaming comet connections. The main downside is just the performance
- since most proxies are designed to hold lots of open connections like a
dedicated comet server is.

However, when it comes to WebSocket, which isnt a standard use of HTTP
(unlike Comet, which is HTTP, just a little hacky), the reserve proxy isnt
going to know what to do with subsequent client->server messages in the
bidirectional communication - that's if it gets passed the handshake part in
the first place.

On Mon, Apr 27, 2009 at 2:12 PM, Salvatore Loreto <
[email-masked]> wrote:

> Hi Martin,
> this is an interesting problem, how Comet behave with "Reverse Proxy"
> do you have any more information : document or link about this problem?
>
> thanks
> Sal
>