Re: [PATCH] external_acl_type format cleanup pt 1

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 07 May 2014 22:35:00 +1200

On 7/05/2014 8:00 a.m., Alex Rousskov wrote:
> On 05/06/2014 10:59 AM, Amos Jeffries wrote:
>> On 7/05/2014 4:01 a.m., Alex Rousskov wrote:
>>> On 05/06/2014 08:37 AM, Amos Jeffries wrote:
>>>
>>>> Several of the external ACL format codes have been added to
>>>> Format::ByteCode_t without equivalent logformat TokenTableEntry's
>>>
>>>> @ Format::Format::assemble(...)
>>>> + // XXX: external_acl_type format codes are not yet output by this code
>>>> + case LFT_EXT_ACL_USER_CERT_RAW:
>>>> + case LFT_EXT_ACL_USER_CERTCHAIN_RAW:
>>>> + case LFT_EXT_ACL_USER_CERT:
>>>> + case LFT_EXT_ACL_USER_CA_CERT:
>>>> + case LFT_EXT_ACL_CLIENT_EUI48:
>>>> + case LFT_EXT_ACL_CLIENT_EUI64:
>>>> + case LFT_EXT_ACL_NAME:
>>>> + case LFT_EXT_ACL_DATA:
>>>
>>> I am not versed enough in Format terminology to quickly grok the above,
>>> so I have to ask: What does the above mean from the admin point of view?
>>> Does the proposed change completely removes support for some external
>>> ACL %macros? Or do we still support everything but require some %macro
>>> renaming for the old squid.confs to continue to work?
>>
>> It means they do not yet produce any output if used in config values
>> other than external_acl_type. There is also no TokenTableEntry using
>> them, so the logformat parser/lexer will also not parse any squid.conf
>> token into those codes.
>
> Sounds good. In summary, certain %codes remain specific to the
> external_acl_type, but the code is massaged to ease their future wider
> support.
>
>
>> - case _external_acl_format::EXT_ACL_UNKNOWN:
>>
>> - case _external_acl_format::EXT_ACL_END:
>> + default:
>> + // TODO: replace this function with Format::assemble()
>> + // For now die on unsupported logformat codes.
>> fatal("unknown external_acl format error");
>> break;
>> }
>
> If it is easy, please use fatalf() to report the offending %code name.
> That would help folks identifying the offending %code among the many
> suspects on a logformat line. This specific change does not warrant
> another round of reviews IMO.
>

We only have access to the numeric enum code at that point.
But done and applied.

Thank you
Amos
Received on Wed May 07 2014 - 10:35:20 MDT

This archive was generated by hypermail 2.2.0 : Wed May 07 2014 - 12:00:11 MDT