W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: multipart, server-sent events, and

From: Mark Baker <distobj@acm.org>
Date: Fri, 15 Feb 2008 17:09:34 -0500
Message-ID: <e9dffd640802151409u4ffae7c2uaef97f1010e81239@mail.gmail.com>
To: "Kris Zyp" <kzyp@sitepen.com>
Cc: public-webapi@w3.org

On 2/14/08, Kris Zyp <kzyp@sitepen.com> wrote:
> > 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.
> I agree, multipart/x-mixed-replace is a strange content type for streams of
>  messages. From a functional standpoint it does not matter, Alex and I simply
>  want something that can provide a stream of messages from the server. From a
>  semantic perspective, x-mixed-replace is supposed to indicate each part in
>  the multipart stream is intended to be a replacement of the previous part.
>  This is nice for webcams (kind of the big use case originally, I think).
>  However, this is not an accurate representation of what is intended with
>  most server-sent message communication, each part should conceptually
>  represent a new message in a log of messages. If multipart handling is to be
>  defined, it may as well allow other more meaningful multiparts content
>  types.
>  Also, I believe multipart/mixed is not intended to have HTTP headers (like
>  Content-Location and many other meaningful headers), only a Content-Type
>  header. multipart/message would be preferable in that it allows the full
>  range of HTTP headers to be included.

It wouldn't be an HTTP header, it would be a MIME header.  But the
MIME multipart syntax supports headers other than Content-Type.
Content-Transfer-Encoding is commonly used, for example.

> I believe the most semantically
>  correct and efficient content type would be message/http, where the content
>  body is itself a stream in the format of HTTP (response) messages. A stream
>  of HTTP messages can easily be partitioning into parts (without requiring
>  the overhead of part boundaries), and each part can have it's own flexible
>  set of meaningful HTTP headers.

Hmm, I wouldn't think so because that would be tunneling.  Anyhow, it
doesn't really matter, as I wasn't necessarily trying to define
something new.  I was - in a round about way - trying to ask whether
it was worth living with the limitations of x-mixed-replace if there
was only one implementation of it around.  If other browsers support
it, then I'd guess it is worth it.  Alex says it almost works in
Safari - presumbly via Webkit functionality - so that's a bunch of
browsers there.

>  >>  * 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.
> HTTP _does_ specify that limit. See section 8.1.4:
>  "A single-user client SHOULD NOT maintain more than 2 connections with any
>  server or proxy."

Blow me down, I'd never noticed that before.  Thanks for pointing it out.

>  By "accounted for" he means that it should be possible to specify that the
>  current XHR connection should not count against the 2-connection limit and
>  the browser should be free to use two additional persistent connections.


>  >>, 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.
> The toggle would allow sites to opt-in, so that servers don't see an
>  increase in parallel connections without consent. Of course the increase due
>  to per-document connection limits would almost certainly be negligible and
>  doing per-document connection accounting all the time would certainly not be
>  opposed by us.

I wonder if this is really necessary, since due to the same-domain
constraint, publishers already have a large degree of control over how
many connections their servers see since they're authoring the pages
that create those connections.  I haven't given this as much thought
as you guys though, so perhaps I'm missing something.

>  Another functionality that I believe would be extremely valuable to expose
>  for XHR would be HTTP pipelining control. Most browsers do not provide HTTP
>  pipelining because of compatibility concerns and performance implications of
>  improperly order requests.

I thought it was just that most proxies don't support it on the
outbound connection.  And I've never seen any ordering problems from
the support, or lack thereof, of pipelining.

But I certainly agree that pipelining control would be really useful.

> However, for conforming servers, pipeling
>  improves performance, and if XHR users could opt-in to pipelining, they
>  could do so with knowledge of their server's pipelining capabilities and the
>  correct request ordering. This can provide a particularly valuable
>  capability in server-sent messaging systems. Requests can be explicitly
>  pipelined on the same connection as a long term streaming response, creating
>  true full-duplex over a single tcp connection (without violating HTTP),
>  which is more efficient and sensible than using two connections for duplex
>  communication. Of course being able to designate pipelining would be useful
>  for performance for general XHR purposes as well.


FWIW, I suspect pipelining control could be targeted for XHR2.

Would you be able to write this up as a concrete proposal for
additions to one or both of the existing XHR spec or the (TBD) XHR2

Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Friday, 15 February 2008 22:09:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC