"Kris Zyp" <[EMAIL PROTECTED]> wrote: > > > As with pipelining, I think this would be better handled at the HTTP > > level than the XHR API level. We could define response headers for a > > server to indicate that it allows more than two connections per client,
> > or alternately that a specific connection should not count towards the > > limit. > > I don't have a big problem with this being defined by headers, that seems > reasonable. It is worth noting that doesn't achieve quite the same effect > as doing it in XHR since there is time elapsed between the time the > request is made and the response headers are received. If two connections > are currently servicing responses, and third connection wishes to declare > itself as an extra connection, from the client side this could be > delivered immediately, but with header based permission, it would have to > wait it's turn. That being said, I don't think these are terrible issues, > and a fixing it at the HTTP level is fine with me. Kris > XHR is an application-level protocol. I am not in favour of permitting XHR clients control over connection-level properties. The HTTP code should be responsible for pipelining and connection management - it is absolutely no concern of the application layer how it achieves its objective, which is simply the transmission of an HTTP request message and reception of an HTTP response message. If the application layer wishes to provide hints that particular features should be avoided, then that would be fine - provided that the HTTP implementation is permitted to ignore the hint. The same goes for cacheing - it needs to be hints from the application, not control. My HTTP code contains adaptive behaviour to deliver the optimum results based on prior history with the servers and proxies with which it is communicating. I'm sure other HTTP clients do similar things. A major part of this is working around known bugs in servers (like the aforementioned failures to support pipelining correctly) and a much lesser part (because the capabilities of conditionally using features are built into HTTP already) taking advantage of features, where possible. My code will tend to assume the worst, until it gets evidence that a given feature works. I do not want to permit the application layer to override my decision not to use pipelining, persistent connections, HTTP/1.1 etc. and cause a breakage by doing so. IMHO, allowing application layers control over low-level communications leads to inoperability, surprising behavioural differences in different environments, and makes proper testing of the application as a whole pretty difficult. -- Stewart Brodie
