acl routines for content-dependent acl's

For several things I am working on, specifically transfer-encodings and content-modifying filters, I want to offer the admins
something in squid.conf like:

acl textfiles content_type text/* x-postscript/*
acl compressed_ce content_encoding gzip x-gzip deflate x-deflate
transfer_encoding_list compressed_te -e transfer-encoding gzip deflate bzip2
transfer_encode allow encoding_list textfiles !compressed_ce

where a content_type acl matches based on the content-type header,
a content-encoding acl matches based on the content-encoding header
a transfer_encoding_list lists a set of transfer encoding routines to apply. The -e flags means exclusive - squid is to choose only
one of those encoders, based on the installed filters and the requesting clients q values for the TE: header entries,
and the transfer_encode has the parameters allow|deny telist acl [acl ...]

moving onto content altering filters (and yes, many such things will break rfc 2616. That's a different issue).
something like:

acl gifs content_type image/gif
content_filter_list block_anim blockanim
client_reply_filter allow block_anim gifs

where client_reply_filter & the c_f_list entries are similar to the equivalent te ones above.

Does this make sense? Should I consider the te example above a specific case of client_reply_filters and just implement the general
case?

(the general case being that new content filters register themselves with squid with a human readable name, and when inserted into
the request chain may need some parameters. I.E the TE request header needs to fill in the q values for various encodings based on
what is compiled in, and I think that should also be admin/acl driven - ie don't ask for compression on requests that end in .tgz -
broken upstream implementations may just compress everything if the TE header allows it. Also things like Joe's project to replace
URL's in accelerated content would be best implemented as a filter that takes the old url pattern and a replacement pattern, rather
than hardcoding that. Secondly filters may want to be in line twice on the same request ( ie using Joe's project as an example
again, if there are two domains being accelerated, then a page with url's to both in it will need the same filter applied twice with
different parameters.) what this means is that the parameters need to be tied to the list of filters, allowing the admin discretion
and flexability).

I haven't dug deeply into the acl framework as yet... are there going to be issues if some admin tries

acl textfiles content_type text/*
http_access allow textfiles

as the http_access occurs before the headers are received?

Any other gotchas that I won't see until too late?

Rob
Received on Fri Jan 26 2001 - 22:29:45 MST