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@xxxxxxxxxxxxxxxxxxx> 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 Sarmadi
