[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