Amos Jeffries wrote:
Chris Robertson wrote:
s f wrote:
hi,
here is the things u mentioned
acl our_networks src x.x.x.x/x
delay_pools 1
delay_class 1 2
delay_parameters 1 -1/-1 2048/8000
#delay_parameters 1 4096/8000
acl dp url_regex -i \.mp3$ \.wmv$ \.avi$ \.wma$ \.mpe?g$
acl dp1 rep_mime_type video/flv
#acl youtube url_regex -i youtube
acl youtube dstdomain .youtube.com #rep_mime_type didnt worked so
currently am having this. but since youtube has
delay_access 1 allow dp our_networks
delay_access 1 allow dp1 our_networks
I think the problem originates from mixing reply_mime_type and src.
Agreed, that should probably be:
delay_access 1 allow dp1 youtube
Except most of the videos are not served from youtube domains (or the
next delay_access line would have worked).
For me, the page http://www.youtube.com/watch?v=mmVaLp8icoU references
the movie at...
http://www.youtube.com/get_video?$longString
...which is a 303 to...
http://cache.googlevideo.com/get_video?$lotsOfArguments
...which is a 302 to...
http://74.125.15.158/get_video?$lotsOfArguments
...which finally delivers the movie.
ie flash videos coming from youtube domains.
At the very least, you should drop the "our_networks" from this
line. On the others it's just redundant.
Not good advice unless we can see the whole config.
He may be running a dual-mode proxy and not wanting the delay pools to
apply to reverse-proxied web traffic. In which case their presence is
vital not to interfere with hosting service times.
Fair enough.
delay_access 1 allow youtube our_networks
delay_access 1 deny all
The delay pool is working for acl dp and youtube. But there is no
effect in youtube videos.
Chris
Amos
Chris
