[squid-dev] [RFC] client header mangling

[Eliezer Croitoru]

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: eliezer at ngtech.co.il


-----Original Message-----
From: squid-dev [mailto:squid-dev-bounces at 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 at lists.squid-cache.org <mailto:squid-dev at lists.squid-cache.org> 
http://lists.squid-cache.org/listinfo/squid-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20160610/72da5080/attachment.html>