Re: Generic helper I/O format

On 05.07.2012 08:34, Henrik Nordström wrote:
> ons 2012-07-04 klockan 13:02 -0600 skrev Alex Rousskov:
>
>> No, it is not. BS is required if the body is present and BS is not a
>> valid key name. Thus, BS cannot be confused with a start of a
>> key-value
>> pair _and_ if a body starts with BS as well, there is no problem
>> because
>> we already know to expect a body there (after BS).
>
> Why do we need a blob marker? Why not simply use key=value pairs
> across
> the board?

We need it as a temporary measure to handle old helpers responses.

I agree on the desire to move to key-pair across the board and am
trying to reach it out of this forest of individual fixed-syntax
parsers. I think its possible (easy even) to do it using a blob instead
of new config settings.

>
>
>> Why not have NtmlHelperReply::setResult() do the mapping? Is there
>> something format-incompatible with those NTLM result codes that the
>> generic parser cannot parse them using the following format?
>>
>> [channel-ID] <result> [key-pairs] [<BS> <blob>] <terminator>
>
> NTLM do not need a blob. It's just a value. Moving to key=value is
> fine.
> Additionally worth noting is that = is not a valid character in NTLM
> blobs so same parser can be used if tokens without = is supported
> (keyless values).
>

Good point here. Same stands for all the other helpers.

Alex,
  before starting I went through each of the helper response styles we
have and documented exactly what comes and goes
(http://wiki.squid-cache.org/Features/AddonHelpers) to determined that
none of the response formats started with a token containing [a-z0-9]
then "=". We are *not* starting from a random-input state where <blob>
can overlap with <key>.

Anything which does not start with a registered <result> status code,
is <blob> automatically. The ones which do use <result> are safely
mapped to the key-pair format based on the presence of a valid "key="
token, or its absence indicating <blob> to be handled by the old parser.

Have a look through that wiki page at the set of "Result line sent back
to Squid" and its clear.

The proposed shared format is *exactly* what external ACL already
processes. It also if you look at the code has the proposed background
<blob> for backward compatibility with some squid-2.5 era helpers which
only sent a <reason> field in plain-text (random input! yuck, as an
established PoC it seems not to have had any complaints).

Amos
Received on Wed Jul 04 2012 - 22:52:26 MDT