Re: pipelining vs. deferred content

Jeffrey Mogul wrote:
> 
> 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.

Isn't this problem effectively solved by multiplexing, which is on the agenda
for HTTP-NG?

I agree that we are unlikely to solve it before DS time! I also shudder to
think of how we'd have to restructure Apache to handle it.

We are planning changes to Apache to be able to do this kind of thing in V2.0,
ETA sometime next century at the current rate of progress.

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Received on Thursday, 27 March 1997 03:45:52 UTC