Re: Extra Connection Support Proposal

"Kris Zyp" <kzyp@sitepen.com> 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

Received on Tuesday, 19 February 2008 19:33:19 UTC