Re: Squid-2.6 update

> Either set up a new branch from squid-2.6, or submit it via squid-dev.
> The latter is perhaps most suitable as it's a small feature ready for
> immediate merge.

Attached is the patch for:
1) external acl grace patch for squid 2.6, leaving 'level' for near (?) future.
2) adds 'srcport', 'myaddr', and 'myport' acl tags.

> But bringing external-acl-fuzzy up to 2.6 is also a good idea for the
> level discussion below.
>
> > I've noticed the 'level' concept in squid2's branch
> > external-acl-fuzzy, which is not present in squid3. I would like to
> > add support for this to squid3, unless someone object.
>
> The cache level concept unfortunately did not work out quite the way I
> had hoped for and is why it has not been merged. It solves some
> problems, but many still unsolved. The problem needs a little more study
> before deciding on what should be done.
>
> The main problem with the existing cache level approach is how to handle
> the acl arguments.

And I guess that a reply of level=N should delete lower levels
(level=n where n < N) from cache. So, for each reply, many cached
entries would be deleted ('N-1' to be precise).

> Perhaps the solution is to simply allow format tags in the acl arguments
> as well, allowing the data to be freely reordered making the cache level
> concept fit much better, or a new format tag which expands into the
> arguments.

Reordering and combining perhaps? Allowing combining would raise the
number of cached entries invalidations from N-2 to (2**N)-2 (I am not
counting current reply as an invalidation).

> Thinking about it a bit further I start to like the idea of introducing
> a new format tag for the acl arguments, with a default of adding the
> arguments added at the end of the request if this tag is not used in the
> external_acl_type specification.

The format tag should expand to some string we are sure is not present
in any other tags, which is something difficult to assure since we
have %{Header:member} tag. Adding 'level' support for external acl
cache implies the request/reply pair need some higher level structure
(say XML, or HTTP-alike), unless I am missing something.

Regards,

-- 
Gonzalo A. Arana