On Wed, 21 Oct 2009 19:02:55 +0500, "Asim Ahmed @ Folio3" <aahmed@xxxxxxxxxx> 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
