Post by Ian HicksonCGIs, today (and PHP, and whatever else) still need the framework to
support them (ie, a webserver that supports CGI, PHP, etc). On a shared
host provider, you typically don't get to install servers, you pick one
that supports what you need - CGI, PHP, or in this case WebSocket
servlets.
The point is that all you should need to use Web Sockets is a shell and a
scripting language.
Even really quite creative people rarely reimplement HTTP to "do web
stuff", so I fail to see why you think this will radically change with
WebSockets.
HTTP is hugely complicated compared to WebSockets. IMHO that's a bug, not
a feature. By making WebSockets trivial to implement, we enable these
"quite creative people" to write their own servers.
I understand and respect those positions.
However, please take a quick look at HTTP's history, because the same
will probably occur to WebSocket.
In the old days, you could write a HTTP server as a short shell script.
Seriously, I saw it done. NCSA Mosaic + shell scripts for servers.
HTTP was seen as a *much* simpler, "lighter" protocol than FTP for
fetching files. That was one of it's touted benefits. Simplicity,
ease of implementation.
Nowadays, it's reversed. I see people installing FTP servers because
HTTP is seen as heavy and FTP is seen as light. Bizarre but true.
Now, the only HTTP servers I see implemented in short scripts - and in
fact in some script libraries that are more widely used - are quite
buggy. Nobody notices because they get away without testing the buggy
parts. (For example, treating HEAD the same as GET, treating OPTIONS
the same as GET, ignoring the Expect header, not passing 1xx headers,
stripping spaces either side of a header name, claiming HTTP/1.1
compliance while not remotely complying, etc.).
I also see, on embedded systems lists, people asking where they can
get a small HTTP server to do this, that or the other. It never
occurs to them to just write one (except in one case I can think of,
where the device's badly written HTTP server for diagnostics was the
reason it kept crashing.) Even though it's actually easy to write a
conforming HTTP/0.9 server.
I think the same will happen with WebSocket: Simple at first, but
before you know it, it'll have evolved - and the web will be full of
dirty workarounds for buggy clients and servers - just like what
happened with HTTP.
When that happens, almost nobody will write an implementation raw in a
few lines of script, and a situation similar to HTTP today will occur.
There will be lots of WebSocket implementations available to choose
from - at least 6 in every major language and another 20 written in C
- and each targetted at a different audience, whether it's
scalability, easy of use from a scripting perspective, minimal size,
single-threaded, etc. So that almost everyone will use one of the
available ones, because it'd be a waste of their time not to.
Post by Ian HicksonOkay, so for the sake of example I'll pretend to agree that the average
weekend hacker will willingly implement their own HTTP framework rather
than just grab some existing one.
There's no need to implement an HTTP framework to use Web Sockets.
+1, fwiw, I do agree with this.
Post by Ian HicksonWhat you seem to be attempting to do is make the protocol sufficiently
hard to implement that you'll either put people off doing so, or else
force them somehow into doing it "right", such that the resulting
weekend hacking project is secure against various XSS style attacks and
other potential hazards.
What I'm attempting to do is make the protocol easier to implement safely
than to implement it unsafely.
I think it'll succeed, but only because these attack-blocking
strategies are too complex to implement in a few lines of script by an
amateur programmer, so they'll cut & paste other people's 5 pages of
code (the old buggy one from 2010 probably), when they decide not to
use libraries or front-ends.
Nearly all such programmers will learn, after one or two tries, that
it's easier to get an off-the-shelf implementation and use it anyway.
Then they can concentrate on their application. This is based on
observing what people do with other protocols - not just HTTP, but at
all layers.
We see people using SOAP after all. Clearly people see simplicity as
whatever pre-packaged APIs they can easily use, not on-the-wire
simplicity. And for whatever reasons, sockets are harder to use than
pre-packaged messaging APIs.
Post by Ian HicksonThe thing is, I think people will be just fine with knowing that if they
knock something together without reading the spec - particularly the
Security Considerations section - then it might turn out to be insecure
in some respects.
But the point is they won't know that. Random authors don't think about
how if they implement their HTML+HTTP+CGI feedback forms incorrectly
they'll make it possible for spammers to launch campaigns from their site.
They don't think about how if they don't generate unique tokens for each
user/form combination they'll expose their users to XSRF attacks. They
often don't even think about how if they don't escape their user's input
they'll be vulnerable to XSS or SQL injection attacks.
I agree with the desire to protect users in this way.
But even random CGI authors tend to use a "CGI library" to read their
environment variables.
Post by Ian HicksonI'm not certain you understand the complexity of a WebSocket
application. Not parsing. Parsing is trivial. Grammars are trivial.
But the threading and synchronization issues are not trivial at all.
For small-scale operations, there's really no need for things to be
particularly complicated. Sure, if you have hundreds, thousands, millions,
or billions of users then it is hard work -- and the protocol's complexity
pales in comparison to the scaling issues. But when there are no scaling
issues, when you have four users _total_, it doesn't have to be hard and
the protocol _can_ be a significant burden.
+1, I agree with the general sentiment. But I think it's doomed to
fail. Especially if the attack-blocking strategies are included, it's
simply too much for many programmers at that point to write their own.
So I think the attack-blocking strategies are fine, but partly because
the added complexity will put some people off writing their own servers.
Let's put it this way: If plain sockets were perceived as easy to
program, why are there people considering using WebSockets for
application-to-application communications (no browser) - instead of
just using plain sockets? Even though plain sockets are obviously
much less work than do-it-yourself WebSockets?
Post by Ian HicksonI think your argument that websocket should be easy to implement by
application developers was probably a lot more valid before websocket
was moved to share port 80 with HTTP.
Now that it is sharing a port with HTTP, I believe the vast majority of
users will be working with HTTP servers that provide websocket support
(just as they provide CGI or servlet support).
I wouldn't expect any of the small-scale authors I've been talking about
to use a privileged port (<1024), least of which port 80.
[...] I don't think we should compromise any real security or
interoperability requirements to specifically target such developers.
On the contrary, targeting such developers actually makes it even more
important that we nail down the security and interop well.
There are three kinds of intermediaries.
1. Explicit client-side intermediaries. These are the ones that the user
would configure their browser to use (either implicitly or through proxy
auto-configuration). These are easy to deal with, and are not a problem.
2. Server-side intermediaries. These are the ones under the control of the
author: reverse-proxies, load-balancers, and the like. It would be optimal
if they could be reused easily, though frankly, at the end of the day, it
is technically possible for the author to wholesale-replace everything on
their network if necessary. It would obviously be a huge impediment to
author adoption.
3. Man-in-the-middle intermediaries. These are typically at the ISP, doing
firewalling, traffic shaping, silent caching, and the like. Sometimes
these are (incorrectly) called "transparent proxies", though that term is
used in the HTTP spec to mean #1 above. These are a huge problem, because
neither the client nor the server knows about them, and they cannot be
updated, upgraded, or replaced by either the author or the client, so if
the protocol cannot tunnel through them, there is no way to deploy the
protocol to the user.
Well put. There's a couple more types, which don't affect the HTTP
handshake but definitely affect reliable WebSocket usage:
4. TCP relays (a couple of flavours, depending on whether they relay
half-closes (shutdown) or full-closes only). Those are used on some
mobile/wireless networks, and some tunnelled environments. This
doesn't affect the protocol bytes, but it does affect orderly
close strategy, and any ideas people may have had about TCP ACKs.
5. Not-quite-intermediary but affects the stream: Stateful firewalls
and NATs, whose ports remain open only as long as there is regular
keepalive traffic - and even then occasionally close randomly - and
always do so if the number of connections (from everyone) exceeds a limit.
4 and 5 are currently things that applications themselves must code
for if they want reliable operation.
Post by Ian HicksonPost by Jamie Lokier1. Standalone WebSocket servers must be easy to write and the
specification easy to understand.
This is essentially meaningless. Can you ever imagine a requirements
document saying: servers must be hard to write and the specification
hard to understand?
Heh, I've seen a few specs which imply it :-)
Some people have said WebSocket's draft falls into this category at
the moment... because people have different ideas about what
constitutes hard to write (some see reusing Apache as easier than
writing a socket program) and hard to understand (opinions vary).
Post by Ian HicksonI agree. That's why I prefer the way I phrased it originally, something
along the lines of "it should be possible to implement a fully-conforming
server in a few dozen lines of code in Python or Perl" or some such.
Oh, that's easy in Perl in 2 lines :-)
use Net::WebSocket::Simple qw(server, send);
server (port => 8910) { send("Response: ".uc($_)) }
It seems to me the dominant culture in Perl and Python worlds is to
use libraries. Maybe that's just the vocal bloggers, though.
-- Jamie