Re: [RFC] Unified Squid helper protocols

From: Kinkie <gkinkie_at_gmail.com>
Date: Mon, 14 Mar 2011 17:05:35 +0100

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

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

-- 
    /kinkie
Received on Mon Mar 14 2011 - 16:05:42 MDT

This archive was generated by hypermail 2.2.0 : Mon Mar 14 2011 - 12:00:04 MDT