On 8/20/2012 4:03 AM, Amos Jeffries wrote:

If you wish. It is a minor regression for the use-cases where traffic is
being fetched from sources other than ORIGINAL_DST. That content should
still be cacheable as it was before. It is done this way for now so that
swapping ORIGINAL_DST in for DIRECT at selection time will be safe, and
that selection point is far too late to create cache entries when it
turns out to be safely cacheable despite the verify failing.


OK got it in a way.
I still dont know exactly what's under the hood so I will leave it for tomorrow for a second pass.


However, I noted that your system is a two-layer proxy and both layers
are MISS'ing. For the Host verification possibility only the gateway
intercepting cache would be forced to MISS by those flags. The second
layer is completely unaware of the intercept or Host error and treats it
as normal forward-proxy traffic, caching and all. I would expect this
situation to appear as MISS on your frontend proxy and HIT on your
backend proxy before reaching the cloud proxy.
Well the thing is... that the urls are dynamic and the second one is to make the object cachable on the first possible.
the first layer(intercepting) actually fetch an internal url such as:
http://youtube.squid.internal/static_naming

and the second layer is fetching the real one which is dynamic.
So the second one is not meant for cache at all and since it's a dynamic url I can not use the second proxy cache for that purpose. (Sucks)

I have used 3.1 for quite long time and was happy with the results so it's not really a big issue to keep using it for now. But I will be very happy for squid to not loose a basic functionality and specially on caching possibilities that is the soul purpose of squid.

I can use a small helper I have used before to schedule object fetching into squid but the setup by itself now was suppose to prevent all of this and to make sure there is one proxy instance that will do all the caching and nothing will be done to fetch objects "manually" into the cache.

Thanks,
Eliezer


Amos

--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il

Reply via email to