Re: multipart, server-sent events, and

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


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

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. 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.
Thanks,
Kris

Received on Friday, 15 February 2008 15:09:32 UTC