babajaga wrote > I emailed you detailed info. > The symptom of the bug would be, that data of one video-request will > receive the storage key of the request for another video, and vice versa. > This can only occur, when you have 2 or more users accessing yt the same > time. > Or one user watching yt in 2 browser windows simultaneously. > So, the more users you have active, the higher the probability, that it > might show up. > > I also sent you a suggestion, how to reduce the probability of the bug to > show up. Unfortunately, I do not see the chance for a fool-proof solution. > Unless, the rewriter has access to the header data of the GET. > AFAIK, this is not possible. read this https://code.google.com/p/tempat-sampah/source/browse/storeurl.pl # for ALL Youtube ( range & non range ) # first you need do this # install package dependencies "apt-get install libfile-readbackwards-perl" # add line below to your squid config and remove "#" # *strip_query_terms off* # acl yutub url_regex -i .*youtube\.com\/.*$ # acl yutub url_regex -i .*youtu\.be\/.*$ # logformat squid1 %{Referer}>h %ru # access_log /var/log/squid/yt.log squid1 yutub # acl redirec urlpath_regex -i .*&redirect_counter=1&cms_redirect=yes # acl redirec urlpath_regex -i .*&ir=1&rr=12 # cache deny redirec # acl reddeny url_regex -i c\.youtube\.com\/videoplayback.*redirect_counter=1.*$ # acl reddeny url_regex -i c\.youtube\.com\/videoplayback.*cms_redirect=yes.*$ # storeurl_access deny reddeny -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Re-squid-3-Head-storeid-tp4659552p4659587.html Sent from the Squid - Users mailing list archive at Nabble.com.
