Hi,
I think the problem is that the delaypool acls are only done by a fast
lookup. That means that not every ACL-type is used in delay_access.
a solution is to include the wanted acl in the http_access, where it is
normally processed and the result get cached so it can be used in
delay_access.
s f wrote:
Hi,
I tried but its not working. I know this is a lame answer but before
mailing you all i even tried with this
delay_pools 1
delay_class 1 1
delay_parameters 1 1000/1000
acl dp rep_mime_type video/flv
delay_access 1 allow dp
The videos from sites like youtube, metacafe, dialymotion plays smoothly.
I verified with access.log and the reqest are there on proxy.
upon checking /usr/local/squid/bin/squidclient mgr:delay, the delay
pool is not currently used.
I again tried with
delay_pools 1
delay_class 1 1
delay_parameters 1 1000/1000
acl dp url_regex \.flv$
delay_access 1 allow dp
But the result is same.
What could be the problem? Have anyone tried putting flash video in delay pool?
- Show quoted text -
On Tue, Mar 25, 2008 at 6:55 AM, Chris Robertson <crobertson@xxxxxxx> wrote:
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
Reply
Forward
New window
Print all
Expand all
Collapse all
Forward all
On Tue, Mar 25, 2008 at 6:55 AM, Chris Robertson <crobertson@xxxxxxx> wrote:
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
