Re: Squid enhancement thought

Allen Smith wrote:

> I'm sorry, I may not have been clear enough. What I was referring to
> is actually redirection (not referral, technically - my
> mis-statement), namely a 3xx status code.

Ok. That clears things up a bit ;-)

> Sure, but as long as you know the client is going to be making the
> request, and it should be cacheable by the available information, why
> not go ahead and request it? It should speed things up a bit, without
> increasing bandwidth (except in cases in which the client is
> interrupted before making the request for the redirected-to page).

For a redirect, Squid does not know if the redirected to object is
cachable or not until actually requesting it from the server. All that
is known is the URL.

Apart from this, all on-demand prefetching is plauged by the same
difficulties:
* What to do if the client does not asks for the object in a timely
manner? This is especially important if the object is large.
* What to do if the resulting object isn't cachable?
* What headers should be used when constructing the request?

The hard part in Squid is implementing the engine for driving the
prefetching, not the HTML or Redirect parsing to fuel the engine with
requests. Parsing HTML in Squid is not that difficult. What is difficult
(with respect to object parsing in Squid) is to modify the HTML code.

--
Henrik nordstrom
Spare time Squid hacker