I am trying to understand so bear with me couple seconds. I have seen that there are pages\servers which doesn't state about the User-Agent in the Vary response while still taking it into account.
The caching side of the picture is storing an object which will never be served. The HIT ratio is a whole other story of the picture. Since I am not inside the code but I do try to understand, currently what happens? How many lookups are done for\per a request? Do we run an object lookup after the response headers was received from the server? Can we predict a Vary object based on the request only?(I assume that it will be an estimated and not absolute certainty if at all) Also let say we have a 1k page ahead, would we want it to be fetched from disk\ram store rather then from the origin server after we told it we want the object? I am almost sure that lowering the disk and ram stored objects should be a goal by itself if we cannot "dig" them up from ram or disk later for any use. A request_header_replace can work only for "generic" ones such as without a language preference such as "br" added to some requests by browser add-ons. Now a step further, I can write a tiny ICAP service that will "handle" common Vary headers from FireFox and other browsers to test how it affects caches in general. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: elie...@ngtech.co.il -----Original Message----- From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of Amos Jeffries Sent: Tuesday, June 7, 2016 2:10 PM To: Squid Developers Subject: [squid-dev] [RFC] client header mangling I've been looking at ways to resolve the long Vary discussion going on in squid-users with a patch that we can accept into mainline. What they (joe and Yuri) have at present works, but only with extra request_header_replace config preventing integrity problems. One way to make useful progress would be to finally add the recurring request for request_header_access/replace to work on client messages in a pre-cache doCallouts hook rather than only a post-cache hook. I am imagining this being done on the adapted request headers after ICAP, eCAP and URL-rewrite have all done their things. And using the same request_header_* directive ACL lists as for outbound traffic. Any alternative ideas or objections? Amos _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org <mailto:squid-dev@lists.squid-cache.org> http://lists.squid-cache.org/listinfo/squid-dev
_______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
