- From: Mark Baker <distobj@acm.org>
- Date: Fri, 15 Feb 2008 17:09:34 -0500
- 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. Ok... > >>, 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. Indeed. 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? Mark. -- 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