Re: [squid-users] any comprehensive list of regex patterns for video blocking available?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 22 Oct 2009 10:57:01 +1300

On Wed, 21 Oct 2009 19:02:55 +0500, "Asim Ahmed @ Folio3"
<aahmed_at_folio3.com> wrote:
> hmm
>
> Amos Jeffries wrote:
>> Asim Ahmed @ Folio3 wrote:
>>> Hi all,
>>>
>>> is there any comrehensive list of squid regex patterns available to
>>> block all famous / known video contents based on request/reply mime
>>> types?
>>
>> Yes. The pattern video/ is very inclusive of all video file types.

oops, quoting error. I did not say this:
>> Can we use video/* to match any type? similarly with audio/* ?

>>
>> To predict your next question the pattern audio/ catches the audio
>> and music types.
>>
>> Neither of these catch the fake MiME types sent be some bad websites.
>> But they need deeper config tricks based on how the site alters the
>> traffic.
>>
>>> Further, does http_reply_access allow use of 'time' acl used in
>>> conjunction with itself?
>>>
>>
>> Yes. http_reply_access can use any of the same types and http_access
>> as well as the extra reply types.
>>
>> The one hitch with http_reply_access is that the request has already
>> been sent and the object is already being received back by the time it
>> is checked. So a whole lot of bandwidth might get wasted on a
>> reply-based denial.
>
> can we block video / streaming contents on http_req_access operator?

No such operator as "http_req_access".

If you meant by that "http_access" ... there are dedicated protocols for
streaming. Streams do not often go through proxies. When they do it appears
as any other media file download or as a CONNECT request where on the
domain and port are known. The CONNECT !SSL_Ports default rule blocks the
CONNECT streams nicely, mime types block most of the rest.

For streams and multimedia objects the wasted bandwidth is smaller than
downloading the whole thing, just something you need to be aware of so not
too surprised.

Amos
Received on Wed Oct 21 2009 - 21:57:05 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 22 2009 - 12:00:03 MDT