[e2e] Number of persistent connections per HTTP server?

[Joe Touch]

Greg Minshall wrote:
>>Besides, how is the client to know what a short request is vs. a long 
>>one? Sometimes even the server doesn't know (when the reply is sent in 
>>chunks)...
> 
> i remember that Van Jacoboson's observation on all this once upon a time was 
> *something like* the server should be in charge of what bits of what URL get 
> sent when since only the server really knows the details (such as, i suppose, 
> sizes, etc.).

Perhaps. However, that would mean the server decides on which connection 
to send a reply, i.e., that the request and reply could come on 
different channels.

That certainly argues for a more FTP-like approach to using connections; 
it would have been useful had the original designers of HTTP not decided 
on their own protocol, specifically because (paraphrased) 'most 
connections will only be for one page'.

Further, as others have observed, sometimes even the server doesn't know 
the sizes (esp. at the time it starts replying). FWIW, these are all 
good reasons to find a way to use multiple connections to let IP do the 
muxing it was intended, and let TCP do the flow control among a group of 
connections rather than per-connection (e.g., RFC2140 ;-)

Joe