Re: [PATCH] adaptation_meta option

From: Tsantilas Christos <chtsanti_at_users.sourceforge.net>
Date: Thu, 27 Oct 2011 14:38:25 +0300

On 10/22/2011 04:03 AM, Amos Jeffries wrote:
> On 22/10/11 03:03, Tsantilas Christos wrote:
>> This option allows Squid administrator to add custom ICAP request
>> headers or eCAP options to Squid ICAP requests or eCAP transactions.
>> Use it to pass custom authentication tokens and other transaction-state
>> related meta information to an ICAP/eCAP service.
>>
>> The addition of a meta header is ACL-driven:
>> adaptation_meta name value [!]aclname ...
>>
>> Processing for a given header name stops after the first ACL list match.
>> Thus, it is impossible to add two headers with the same name. If no ACL
>> lists match for a given header name, no such header is added. For
>> example:
>>
>> # do not debug transactions except for those that need debugging
>> adaptation_meta X-Debug 1 needs_debugging
>>
>> # log all transactions except for those that must remain secret
>> adaptation_meta X-Log 1 !keep_secret
>>
>> # mark transactions from users in the "G 1" group
>> adaptation_meta X-Authenticated-Groups "G 1" authed_as_G1
>>
>> The "value" parameter may be a regular squid.conf token or a "double
>> quoted string". Within the quoted string, use backslash (\) to escape
>> any character, which is currently only useful for escaping backslashes
>> and double quotes. For example,
>> "this string has one backslash (\\) and two \"quotes\""
>>
>>
>> This is a Measurement Factory project
>

I am sending a new patch here, which is also updated to apply to the
latest trunk.

>
> Cool. I like.
>
> I just have one doubt on the design end of things. Can we limit it to
> not overwriting or adding standard headers? rather than just warning.
> Adding custom headers and ones needed for future protocol extensions is
> all fine and well. But wrongly adding central protocol headers midway
> down a chain is an attractive trap newbie admin are always asking about
> how to do, even if though breaks the final result.

Do we have any decision here? Should we deny overwriting standard headers?

>
>
> src/ConfigParser.cc:
> * s/ debugs(3, 0,/ debugs(3, DBG_CRITICAL,/
fixed.
>
> src/acl/Checklist.cc:
> * more efficient version applied to trunk separately.

removed in this patch.

>
>
> Amos

Received on Thu Oct 27 2011 - 11:38:39 MDT

This archive was generated by hypermail 2.2.0 : Fri Oct 28 2011 - 12:00:11 MDT