Patrick McManus writes:
At the risk of introducing meaningful background literature:
I direct folks to 14.36.1 "Byte Ranges" which when interleaved with
pipelined requests comes very close to achieving client-driven
multiplexing that I'd suggest from a UI pov will behave much better
than the multiple connections method (eliminating the cost of tcp
congestion control but at the cost of some application protocol
More than application overhead, I suspect the biggest problem with this
otherwise good idea is that it won't be implemented corrently by the
browsers or the servers.
For example on the server end, it would see multiple requests for the
same object, at different byte ranges. If that object is being created
on the fly by a program process (e.g. CGI) the browser won't have a
clue of the size.
What is the correct behaviour of the server if the request is made for
bytes 0-2047 of an object which invokes a CGI program to create that
object? Obviously it can send the first 2048 bytes, but then what?
Should it leave the process pipe blocked until the next request comes
in? One httpd listener might well have to have dozens of these stalled
processes. Should they all remain there until the persistent connection
Of course with multiple connections, you have all these processes, anyway.
But at least you know when the process should go away (when the connection
If the persistent connection gets dropped before all the object get loaded,
then loading _must_ start from the beginning, since objects may now become
inconsistent (a different GIF image can be created by a new instance of the
program that generates it).
Of course, all of this can be done. But can you trust the developers of
every browser and every server to get it right? What I am saying is that
if this is to be pursued, it needs to be pursued with a lot of details
addressed that even the RFC doesn't seem to touch on.
Consider CGI. Should the server start a new instance of CGI for each range
request, passing that request via the CGI environment? Or should the server
keep each CGI persistent as long as each range request is sequential to the
previous one? What if there are two different requests for the same path,
which in the ordinary case can indeed generate distinctly different objects
(not cacheable). How would the server know which of them to continue when
the next range request comes in (previously the distinction is managed by
While I can see that persistent connections with range requests can solve
many things, I believe the implementations will botch it up in most cases
to the extreme that it won't get used. A subchannelized method of doing
request/response transactions over a single persistent connection would
handle more (if not all) of these cases better (IMHO).