Re: persistent conncetion HOL blocking

> The same paragraph says:
>    A single-user client SHOULD NOT maintain more than 2 connections
>    with any server or proxy.
> 
> The reasoning behind that requirement is related to a kind of
> head-of-line blocking.

Although, in the case of a proxy if a client is trying to get requests
from a number of different servers, through the same persistent connection
to a proxy, then it's not too difficult to get in a situation where a
proxy can't immediately return a response to the client because it's not
ready or able to reply to a previous request (on that same connection) 
from the client.

For example, a client could pipeline requests to a.com and b.com through a
proxy. b.com might be fast and reply right away to the proxy, but the
proxy can't forward the data to the client because a.com hasn't replied
yet (and thus the response from b.com must be queued).  Even though the
client can maintain two connections to the proxy, this doesn't eliminate
the problem (although it does make it less likely).  The problem can also
because worse in the case where b.com is cached by the proxy (or a delta
[i.e., "IM:" header ] can be computed for b.com), but a.com is not cached.

Adjusting HTTP so that responses can be returned back in a different order
from requests would be one way to address the issue.  It would also be
useful in the case where two requests are made to the same server, and the
second request can be serviced much sooner than the first request (e.g.,
the first request might be some sort of CGI request).  In the case of a
significant amount of pipelining, the feature would also give a server the
ability to choose the best order in which to produce responses (e.g., long
MP3s last).  I'm personally not a fan of "enhancing" protocols, so I'm
interested in any suggestions that people might have for working within
the current confines of HTTP.

MD

Received on Friday, 12 May 2000 11:49:58 UTC