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

Ian,

On Fri, Jan 9, 2009 at 5:35 PM, Ian Hickson <ian@hixie.ch> wrote:
>
>
> Hi,
>
> 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.

This one comes for free with XHR/HTTP, no?  Unless you meant something
more than what's written there.

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

This seems to be the big value-add, and I agree it's desirable.

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

Depends what you mean by "existing".  Waka[1] sounds like it would
address all those requirements.  It has the advantage of being a full
HTTP replacement protocol too, meaning that it's still the Web and so
still suitable for use over ports 80 and 443 (whereas Web Sockets is a
tunnel for potentially arbitrary applications).  It also means that
developers will be starting with something quite feature rich and so
will be less prone to reinventing those features poorly (possibly
inefficiently, or worse, with security problems).

On the downside, Roy hasn't published the protocol yet.

 [1] http://en.wikipedia.org/wiki/Waka_(protocol)

Mark.

Received on Tuesday, 13 January 2009 06:03:45 UTC