Re: [PATCH] adaptation_meta option

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
>
>
> 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.

System administrators in many cases need some extra freedom to make
things which look wrong, for example to make a workaround, or just test
the behaviour of their servers.
My opinion is that we should not be so strict, unless we want to prevent
difficult to detect problems...

>
>
> src/ConfigParser.cc:
> * s/ debugs(3, 0,/ debugs(3, DBG_CRITICAL,/
OK.

>
> src/acl/Checklist.cc:
> * more efficient version applied to trunk separately.

Yes,yes I know. It was here for testing, I just forgot to remove before
sent the patch. Sorry...

>
>
> Amos
Received on Mon Oct 24 2011 - 08:16:53 MDT