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
