On 8/20/2012 2:37 AM, Eliezer Croitoru wrote:
On 8/20/2012 1:38 AM, Amos Jeffries wrote:
The FFFFFFFF is the file number/name where it is being stored. Since
this is an erased operation that is always the magic F value.
It is not 1-to-1 related to the object being cacheable. It just means
the object *currently* stored needs removing. Non-cacheable objects the
RELEASE immediately follows storage, for cacheable objects being
replaced the erase of old content immediately follows storage of new
copies.
OK
<SNIP>
just a bit more interesting data.
there is a different between intercepted requests(NAT and TPROXTY) to
using regular proxy http requests.
on regular proxy everything works fine and the file is being cached always.
(I use two squids.. both with url rewriter that causes the like
"store_url_rewite" effect on the cache.)
it works always for youtube on the same setup so I dont really know what
the cause can be.
it narrows down the bug into a very small area which is:
3.2.1 TPROXY\INTERCEPT + cache_peer + specific requests
vs
3.2.1 regular proxy + cache_peer + specific requests
there is a different in the requests that was made on regular proxy or
intercepted requests that the url has a "@" sign in it but it's not
suppose to change a thing.
I will file a bug later but I want first to verify more about it.
also tested with squid 3.1.20 with the same exact setup using
intercet\tproxy\forward proxy and in 3.1 it all works just fine.
so it's a bug in squid 3.2.1
Thanks,
Eliezer
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
