[squid-dev] [RFC] client header mangling
Alex Rousskov
rousskov at measurement-factory.com
Sat Jun 11 00:07:24 UTC 2016
On 06/07/2016 05:09 AM, Amos Jeffries wrote:
> 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.
Disclaimer: I have not read the Vary discussion on squid-users. I
suspect your RFC is generic enough to ignore that discussion as far as
the RFC is concerned.
> 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 assume that by "finally add" you meant something like "finally implement".
> I am imagining this being done on the adapted request headers after
> ICAP, eCAP and URL-rewrite have all done their things.
Sounds good.
> And using the
> same request_header_* directive ACL lists as for outbound traffic.
I am not sure exactly what you mean, but which headers/transactions to
mangle should be up to the Squid admin. The pre- and post-cache mangling
will often differ. The pre- and post-cache mangling API will be very
similar, of course, but we should not restrict the admin to a single set
of rules that is always applied on both sides of the cache.
One elegant way to implement this would be to add a vectoring-point ACL
that will match "pre-cache" and "post-cache" vectoring points (at
least). That way, you do not need to add new directives but admins can
mangle headers differently on each side. I suspect these ACLs would be
useful in other contexts as well.
As for "eCAP versus squid.conf" mangling, I suggest the following rules
of thumb:
0. Message body mangling belongs to eCAP/ICAP.
1. If header mangling decisions require information contained in the
message body, such mangling belongs to eCAP/ICAP.
2. Header field mangling that cannot be expressed using "add field",
"delete field", or "a regex substitution of the field value" operation
belongs to eCAP/ICAP.
3. All other mangling actions can be supported directly in squid.conf,
at any vectoring point.
Thank you,
Alex.
More information about the squid-dev
mailing list