Re: pipelining vs. deferred content

delabeau@iniki.gsfc.nasa.gov writes:
    My proposal is that the server say, in effect, "Here's your page;
    reserve space for an image and wait just a sec until I give you
    something to fill the space."

I agree, this is an optimization that one might hope to make.
    
Ari Luotonen <luotonen@netscape.com>
    This can already be accomplished by providing the image dimentions in
    the IMG tag.  The only time the client halts layout is when it doesn't
    know the image dimentions, that is, they were neither in the IMG tag,
    nor yet received as first bytes of the image itself.

Actually, this doesn't entirely solve the problem.  If you have
an HTML file with, say, 41 embedded images, and image #3 will
take 10 seconds to precompute at the server, you would really
like to be able to use the network to load images #4 - #41
while that is happening.  The IMG tag allows the browser to render
the bounding box, but it doesn't solve the retrieval serialization.

In the current world, you would probably do that by using another
TCP connection, and that might be an acceptable approach, if it's
only a few "deferred" images per page.  But it does force you
to fire up another TCP connection, and if you have already issued
a pipeline full of requests for images #4 - #41 behind the request
for image #3, then there are some messy issues to worry about
(i.e., how to quash the redundant requests without a lot of waste).

Another approach that would probably work with HTTP/1.1, but would
not be compatible with HTTP/1.0 clients, would be for the server
to respond to the initial request for the "slow" image by sending
	HTTP/1.1 503 Service Unavailable
	Retry-after: 10
(using the example of a 10-second delay).  This would allow the
server to continue processing the pipeline of requests for
images images #4 - #41, because it would not have to stall the
response for image #3.  At the same time (assuming some parallelism
between image generation and HTTP/TCP processing at the server),
it could go ahead and generate image #3, but save the result in
a temporary cache.  So, after 10 seconds, when the client retries
the request for image #3, it now is available immediately.

As I said, this isn't interoperable with HTTP/1.0, or even with
an HTTP/1.1 client that doesn't support Retry-After, so it's not
clear that this is actually a solution.

I think this is a problem worthy of some more thought, but I
doubt we'll solve it before we need to progress HTTP/1.1 to
Draft Standard.

-Jeff

Received on Wednesday, 26 March 1997 15:38:16 UTC