RE: Providing two-way communication back to a server from a Web page

Ian Hickson wrote:
> In collecting requirements for developing the HTML5 specification, on
> particular problem kept coming up: how to get two-way communication
> back
> with a server in a cleaner way than repeated client-pull. It can be
> summarised as these requirements:
> 
>  - The ability for Web pages to send arbitrary text to the server from
> a
>    script in a Web page, in the form of ordered discrete blocks.
> 
>  - The ability for Web servers to send arbitrary text to a Web page
> that
>    has established a connection, in the form of ordered discrete
> blocks.
> 
>  - Text messages should support all of Unicode.
> 
>  - The protocol should support running over ports 80 and 443, ideally
>    with the ability to share the port on the server with an HTTP
> server.
> 
>  - It must be possible to implement a fully-conforming server-side
>    component for this in a few dozen lines of scripting code, in the
> case
>    where sharing the connection with an HTTP server isn't required.
> 
>  - The must be extensible so that it can be extended to support binary
>    data and structured data in both directions in the future, without
>    breaking deployments from the first generation.
> 
>  - It must not be possible for the mechanism to be used to
successfully
>    connect to existing servers and send them arbitrary commands. In
>    particular, SMTP, HTTP, HTTPS, IMAP, POP, and similar protocols
must
>    be safe from this.
> 
>  - It must be possible to connect to arbitrary remote hosts, but
>    connections to these hosts must only be allowed if the remote host
>    explicitly opts in to allowing that Web page to connect (ideally
>    using the 'origin' convention).
> 
> I would be interested in any suggestions people may have along these
> lines. Are there existing protocols that satisfy these requirements?
> 
> 
> There is a straw-man proposal for such a protocol in HTML5, which I
> recently converted to Internet-Draft form:
> 
>    http://www.ietf.org/internet-drafts/draft-hixie-
> thewebsocketprotocol-01.txt
> 
> Any comments on this, or suggestions for a better way to do this,
would
> be welcome.
> 
> For what it's worth, the API that is being proposed (somewhat
> independent of the protocol) is currently at:
> 
>    http://dev.w3.org/html5/websockets/
> 
> You can see both together here:
> 
>
http://www.whatwg.org/specs/web-apps/current-work/multipage/#network

Hi Ian,

I've already been getting some CherryPy users asking if the next version
of CP will support WebSockets. My initial thoughts:

First, just want to agree that finding a better bidirectional mechanism
would be nice.

Second, Python web frameworks at least have pretty much standardized now
on the Web Server Gateway Interface [1], which is strictly
request/response. Rewriting WSGI, and/or extending the servers, to use
WebSockets would be nontrivial. I imagine most other existing web
frameworks in other languages are similarly bound to that model.

Third, I've seen too many custom TCP protocols in my day, and am quite
concerned this would be a step backwards into some pretty ugly RPC. Not
just hard to read, but lacking any visibility or most of the other
network-architectural benefits we've come to rely on in HTTP.

Fourth, if I were implementing bi-directional communication in an HTTP
environment that was machine-to-machine (as opposed to
user/agent-to-machine), I would naturally consider making both ends
expose an HTTP server interface: the "origin server" would expose a
POST'able subscription resource, and the "client" would POST a URL from
its own space. The "server" could then POST updates to that URL; that
is:

    client.user.com
    ---------------
    POST server.biz.com/resource/poll_me HTTP/1.1
    ...
    myurl=client.user.com/listeners/A

...then, at intervals when there is new data to be pushed:

    server.biz.com
    ---------------
    POST client.user.com/listeners/A
    ...
    eventtype=update&data=blahblahblah

Synthesizing those, I'd feel better about WebSockets if the messages
passed in both directions were HTTP, not opaque binary formats. I also
wonder if this couldn't be better achieved by creating a spec (HTTP 2?)
that allowed pipelined HTTP request and response messages in both
directions arbitrarily.


Robert Brewer
fumanchu@aminus.org

[1] http://www.python.org/dev/peps/pep-0333/

Received on Friday, 9 January 2009 23:14:09 UTC