Re: Range processing

On Fri, Apr 05, 2002, Henrik Nordstrom wrote:

> a) The simple path: If what you have cannot fully satisfy the request, then
> ingore what you already have and forward the full request. Then if the new
> reply is compatible with what you have (same strong ETag) then optionally
> attempt to merge the two to form a larger subset of the object.
>
> b) The advanced path: First try to fetch the missing pieces. If the new reply
> is compatible with what you have then make a combined reply to the client,
> else discard both and forward the full request.

Ok.

> I don't think all of this kind of logics belongs at the store layer at all.
> It belongs at a HTTP proxy layer acting as a interchange between the client
> side, store and upstream protocols. In Squid this layer is not existing as a
> isolated layer but distributed over client_side.c and the protocols.

Yup. I'm trying to remove all of the 'cache' related functionality
in client_side.c - eventually it'll go into a http-aware caching module,
but.. well, when I get to this it'll entail turning squid back into
a proxy-only program for a while, whilst all of the caching gunts are
rewritten. Once thats done, range requests should come back. :-)

on a side note, the new storage manager ideas may interfere with
ICP throughput (you don't have an enforced index in memory anymore)
and _will_ interfere with cache digests (there's no enforced index
in memory to build it from). These two steps will take the longest to
sort out efficiently. I'm open to ideas, but please keep them to yourself
for a few more weeks - I need to pay more attention to my studies. :)

Adrian
Received on Wed Apr 10 2002 - 19:17:20 MDT