On Mon, 9 Feb 1998, Phil Howard wrote:
Patrick McManus writes:
At the risk of introducing meaningful background literature: ftp://ds.internic.net/rfc/rfc2068.txt
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 overhead).
As a server implementor, let me simply say this makes no sense and is a perversion of what byte ranges are intended for. You will end up repeating the request headers (which can be sizable) far too often, will put far too much load on the server, will break whenever you get dynamic content, etc.
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?
For dynamic content, it normally has to send the whole document. That is a legal response to a byte range request.