Hmm, I wouldn't think so because that would be tunneling.
The difference between message separation with MIME multi-parts and HTTP
messages is that multi-parts are separated by boundaries and HTTP messages
are generally encapsulated by Content-Length (other ways too). The
difference in efficiency is actually probably a wash. I just believe the
semantics of HTTP messages are highly meaningful on the web.
"multipart/message" is another another multipart format that indicates each
part may have more headers than simply Content-Type (and transfer encoding),
and therefore is more flexible than multipart/mixed, IMO...
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.
Even if it is based on a current implementation, the standard will be new,
and it seems like we might as well as allow for other content types that are
more reasonable than x-mixed-replace. It is not high-cost and it seems like
good progress towards a more sane future.
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.
Publishers don't have control over how many tabs the user opens for the same
site though. Four tabs to the same site means that the each tag/page may
want it's own persistent connection to the server, but it is still one
browser/agent.
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.
Yes, this is true. But browsers (at least firefox) do use heuristics to
determine whether or not to pipeline requests (even when it is enabled).
Admittedly, I don't what those heuristics are, but I presumed they were
guesses about the extent of support. Also pipelining can possibly slow
things down if a certain request takes a long time and it has requests
stacked behind (that otherwise would have been diverted to another
connection). All of these things web devs could have knowledge and control
over though, and so opt-in pipelining could avoid these issues.
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
spec?
Yes. Are you referring specifically to pipelining, or other matters
discussed? Either I will do that.
Thank you,
Kris
