Re: multipart, server-sent events, and


On 2/11/08, Alex Russell <> wrote:
> Howdy all:
> So after some brief discussions with Anne and Hixie, I want to start a
> discussion about some of the open issues I see not being addressed regarding
> server-sent data. This was agreed as the correct forum for the discussion. I
> see several major issues that need resolution:
>  * what will become the (defacto) standard for multiple events over a single
> connection?
>  * what will be done to prevent the current 2-connection limit from locking
> browsers?
> First, as background, there are at least 2 partially-implemented solutions
> available in browsers today. Opera has included an implementation of the
> WHATWG's sever-sent events, which rely on a simple wire format. The other
> native option for receiving multiple messages without closing/re-opening a
> connection is the multipart/x-mixed-replace system (currently implemented in
> a semi-workable fashion by Mozilla).

I always wondered why plain old multipart/mixed was never used, with
Content-Location headers per part.  It would even be more general,
permitting multiple streams to be muxed over a single connection.  Is
there just the one implementation of x-mixed-replace?

> Given that WHAT-WG seems to be leaning away from server-sent events, and
> noting that neither approach solve the 2-connection limit problem, I'd like
> to propose the following for consideration:
>  * that multipart/x-mixed-replace for textual content over XHR be fully
> specified by this working group
>  * that a new XHR readyState be defined for "message end" as distinct from
> HTTP connection close or that some other property or event be made available
> to test for overall connection state

Presumably you're referring to an event per part here, so perhaps
"part end" instead of "message end"?

>  * that a new settable property be added to XHR objects which controls how
> the HTTP connection created by the object is accounted for against the HTTP
> 1.1 specified 2-connection limit.

Not sure what you mean by "accounted for", but HTTP doesn't specify
that limit, it's just defacto via implementation.

> Today, if multiple tabs open Comet connections to the same originating
> server, no document in the browser may request any resources from that
> server, effectively "locking" the domain from further use until one of the
> Comet connections is closed. Instead of a blanket "bump" to the connection
> limit (which has un-desireable consequences for existing servers)

Indeed.  Yes, let's not do that.

>, it may be
> preferable for servers to be able to provide a header which effectively
> discounts the connection or a client-side toggle which allocates the
> connection against a different, per-document limit of connections (up to
> some high global maximum).

What would the toggle do?  It seems to me that browsers just need the
per-document connection limit you mention.

I reckon I'm asking for a bit more detail on your proposal, but it
does seem headed in the right direction.

Mark Baker.  Ottawa, Ontario, CANADA.
Coactus; Web-inspired integration strategies

Received on Thursday, 14 February 2008 19:09:56 UTC