Re: [RFC] Unified Squid helper protocols

 On Mon, 14 Mar 2011 10:46:21 -0600, Alex Rousskov wrote:
> On 03/14/2011 10:05 AM, Kinkie wrote:
>>> You could handle encodings in the low-level value parser as well if
>>> you
>>> make them explicit:
>>>
>>> name="string with some documented quoting rules"
>>> name=base64:base64encodedvalue
>>> name=rawvalueterminatedbythefirstwhitespace
>>>
>>> The latter assumes no raw value can start with "base64:". Other
>>> quoting/encoding mechanisms are possible, of course.
>>
>> Why put that in the message, if we can do it in the label, and avoid
>> all quoting issues altogether?
>
> Not sure what you mean by "label", but it is easier to write parsers
> and
> extend functionality when parsers and packers do not rely on name
> semantics to properly handle the message.
>
> If you meant moving value "base64:" prefix to the "name" suffix, that
> is
> possible, of course, but keeping the encoding of the value closer to
> the
> value itself is more "natural", and it would be a little easier to
> write
> value encoders that way, IMO. I do agree that using name suffix will
> help avoid encoding specs/value clashes.

 I did't really want it to get that complicated just yet. Once the
 receiving parsers in squid are unified they can be extended to do all
 this. FWIW there is base-64, RFC-1738, shell, quoted, raw binary and
 two-way crypto encodings which ALL might appear here.

>
>>>> The parameter message= is added with a quoted string value to
>>>> allow
>>>> other parameters on the same result line when an error
>>>> reason/message is
>>>> sent back.
>>>>
>>>> The parameter user= is added to hold the username whenever
>>>> relevant for
>>>> any reply.
>>>>
>>>> Other parameters are on the planning board for addition after the
>>>> changes. So far I have: ttl= for setting a desired
>>>> credentials-TTL,
>>>> group= for associating a group name with the user=, tag= extended
>>>> from
>>>> external ACL to auth.
>>>>
>>>>
>>>> Opinions? problems? other ideas?
>>>
>>> I do not know much about existing helpers, but I would recommend
>>> using
>>> the same set of basic syntax rules for _all_ messages:

 Agreed. That was the plan. My description for the semantics of several
 name= tokens has no bearing on the underlying receiver parser. That is
 purely semantics in the end helper and handling components.

 The line receiver only needs to care if:
  * is it "" around something containing whitespaces?
  * is it a single series of bytes with guaranteed no space characters?

 There is no low-level differential between token=<base-64_blob> and
 user=<username>
 There is between message="raw text with possible binary" and
 message=<base-64 encoded blob>

>>>
>>> <responsecodeterminatedbywhitespace> [name=value]*
>>> where the value syntax is as discussed above. This approach would
>>> make
>>> writing a general response-buffer-to-response-structure parser easy
>>> and
>>> simplify addition of new fields or extensions.
>>
>> I agree, with a proposed modification (pseudo-regex syntax):
>>
>> <responsecodeterminatedbywhitespace> (name(:enc)?=value " ")*
>>
>> Where :enc, if specified may be ":b" (base64-encode), further codes
>> to
>> be added as needed. As a separator we could use something different
>> from space to further reduce the risk of clashes.

 I like. Though this does make the low-level user-facing parts a bit
 more complicated.

 Amos
Received on Mon Mar 14 2011 - 22:22:45 MDT