Re: Persistent connections: aborting requests in progress.

Paul said:
    It also needs a way to interleave responses from the pipelined 
    requests, else long ones will delay shorter ones. Think about the 
    concurrent "progressive rendering" of multiple GIF and JPEG files that 
    currently is done using multiple connections, and what it would take to 
    do it with pipelining.

As Simon has already pointed out, HTTP-NG (which may end being called
HTTP 2.0, I guess) already proposes mechanisms to get away from a simple
byte-stream model.  I think this is probably too much of a jump for
HTTP 1.x.

Further, I think "needs" is too strong a word.  If one measures
the total latency to retrieve and fully render a page with inlined
images, a single persistent HTTP connection will almost always
finish faster than N separate single-request TCP connections.  So
even without interleaved responses, P-HTTP would be "faster" in
this sense than what we have today.

Of course, Netscape users have come to expect early rendering of
text layout because Netscape can discover the shape of the first
four (or so) images before fully retrieving any of them.  I agree
that this is a valuable property to preserve.  Several months ago,
we had a somewhat noisy debate about other techniques for early
delivery of image size and shape without having to use Netscape's
parallel-connection model.

I believe we never came to a conclusion at that time.  If I recall
my own preferences (I could have this wrong), I strongly favored
inventing a new HTTP method that would return the "shape" of an
image without returning the whole thing.  So, a typical retrieval
of a page with four images might look like:

	GET page.html
	<one RTT delay>
	GETSHAPE image1.gif
	GETSHAPE image2.jpeg
	GETSHAPE image3.gif
	GETSHAPE image4.gif
	GET image1.gif
	GET image2.jpeg
	GET image3.gif
	GET image4.gif

Note that, unlike the Netscape model, which breaks down if you
need more than 4 images to decide how to render the text, this
mechanism scales to arbitrary numbers of images.  It doesn't
allow the browser to render several images simultaneously, but
I think that is a much less useful feature if the alternative
is faster completion for all images!

Someone will no doubt flame me for suggesting that the server
has to understand the shape of images.  Go ahead, flame away;
I'm leaving for a two-week trip in 30 minutes, so I won't be
around to defend myself.  But I'll point out that we could
make server support for GETSHAPE optional, without affecting
correctness (and in thise case a greedy browser could always
revert to a parallel-connection approach).

    ] Since the protocol currently does not have a way for the server to
    ] abort the transmission of a response once it has started it, presumably
    ] we would also need to use the Urgent Pointer mechanism to do that.
    
Thinking about Harald's reply, I'm almost ready to concede that URG
is a bad idea, and that occasionally firing up a second TCP connection
to bypass the one being aborted is the simplest approach.  However,
this does require some complexity on the server side: since the
old retrieval is taking up bandwidth, the server should stop it as
soon as possible.  But this requires two things:
	(1) multi-threading (perhaps using separate processes) on the
	server, so that it can process the new connection before
	finishing the old one.
	(2) communication between the new thread and the old thread,
	so that the new thread can suppress the old response and thereby
	free up the bandwidth of the response-path.
Implementing #2 might not be all that simple on all platforms.  The
problem with URG is that it's not exactly reliable or consistently
implemented, but perhaps we can figure out a way to deal with the
ambiguity.  For example, transmitting a few extra pad bytes so that
any off-by-one errors disappear in the normal "remove white space"
processing of headers.

-Jeff

Received on Tuesday, 12 September 1995 10:20:42 UTC