[whatwg] WebSocket support in HTML5
shannon at arc.net.au
Sun Sep 21 21:09:24 PDT 2008
Richard's Hotmail wrote:
> My particular beef is with the intended WebSocket support, and
> specifically the restrictive nature of its implementation. I
> respectfully, yet forcefully, suggest that the intended implementation
> is complete crap and you'd do better to look at existing Socket
> support from SUN Java, Adobe Flex, and Microsoft Silverlight before
> engraving anything into stone! What we need (and is a really great
> need is someone re-inventing sockets 'cos they think they can do it
> Anyway I find it difficult to not be inflammatory so I'll stop now,
> but please look to the substance of my complaint (and the original
> it is that you are putting all these protocol restriction on binary
> socket support.
It's hard to determine the substance of your complaint. It appears you
don't really understand the Java, Flex or Silverlight implementations.
They are all quite restrictive, just in different ways:
* Java raises a security exception unless the user authorises the socket
using an ugly and confusing popup security dialog
* Flex and Silverlight requires the remote server or device also run a
webserver (to serve crossdomain.xml). Flex supports connections ONLY to
port numbers higher than 1024. The crossdomain files for each platform
have different filenames and appear to already be partly incompatible
between the two companies, hardly a "standard".
Both Silverlight and Flash/Flex are fundamentally flawed since they run
on the assumption that a file hosted on port 80 is an authorative
security policy for a whole server. As someone who works in an ISP I
assure you this is an incorrect assumuption. Many ISPs run additional
services on their webserver, such as databases and email, to save rack
hosting costs or for simplicity or security reasons. I would not want
one of our virtual hosting customers authorising web visitors access to
those services. It is also fundamentally flawed to assume services on
ports greater than 1024 are automatically "safe".
These companies chose convienience over security, which quite frankly is
why their software is so frequently exploited. However that's between
them and their customers, this group deals with standards that must be
acceptable to the web community at large.
The current approach the HTML spec is taking is that that policy files
are essentially untrustworthy so the service itself must arbitrate
access with a handshake. Most of the details of this handshake are
unjustified. If you are worried about the complexity of implementing the
server end of the service I can't see why, it's about 3-6 lines of
output and some reasonably straight-forward text parsing. It could
easily be done with a wrapper for existing services.
Other than that it behaves as an asynchronous binary TCP socket. What
exactly are you concerned about?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg