The delay_pool and ACL directives that I've used are:
===============================
# Multimedia file extension, -i : case insensitive
acl mm_ext urlpath_regex -i \.mp3$ \.avi$ \.mov$ \.mpeg$ \.mpg$
\.divx$ \.mp4$ \.xvid$ \.axf$ \.3gp$ \.img2$ \.wma$ \.wmv$
acl compressed urlpath_regex -i \.rar$ \.zip$
acl executablebinary urlpath_regex \.exe$ \.msi$ \.bin$ \.iso$
#delay_pools
delay_pools 3
delay_class 1 2
delay_class 2 2
delay_class 3 2
delay_parameters 3 25000/25000 25000/25000
delay_parameters 2 260000/260000 260000/260000
delay_parameters 1 35000/35000 35000/35000
delay_initial_bucket_level 50
delay_access 3 allow executablebinary
delay_access 3 allow compressed
delay_access 3 deny all
delay_access 2 allow needbw
delay_access 2 allow !mm_ext !executablebinary !compressed
delay_access 2 deny all
delay_access 1 allow mm_ext
delay_access 1 deny all
===============================
I hoped that URLs with Multimedia, Binary, ... extentions could fall
in delay_pool number 1, but all of them fall into delay_pool number 1.
I guess the problem is I could not match urlpath_regex in an HTTPS
session, isn't it?
If yes, Any clue?
On 6/25/06, Henrik Nordstrom <henrik@henriknordstrom.net> wrote:
> sön 2006-06-25 klockan 01:41 +0330 skrev Mehdi Sarmadi:
> > Could https requests/replies fall in delay_pools?
>
> Yes.
>
> > If yes, How to?
>
> Should by default, unless you use some incompatible ACLs in your
> delay_access...
>
> As for all the other protocols the delay pools only applies on
> internet->client traffic. Not client->internet traffic.
>
> Regards
> Henrik
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEncOzB5pTNio2V7IRAhLvAJ4kTjglxuxCFER/fqm32cFgyz7k4wCfUO/Y
> 3v285H3EE/v9aT/YWMKf4Yg=
> =3YVr
> -----END PGP SIGNATURE-----
>
>
>
-- Mehdi SarmadiReceived on Sun Jun 25 2006 - 01:20:39 MDT
This archive was generated by hypermail pre-2.1.9 : Sat Jul 01 2006 - 12:00:02 MDT