Re: [RFC] Unified Squid helper protocols

On Mon, Mar 14, 2011 at 5:46 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> 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

Yes, I used "label" in place of the "name" (see the example at the end
of the previous mail:

> <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 agree that encoders may be easier, while using the name-based
approach would IMVHO make decoders easier :)
I tend to favour the latter as they generally carry more security
risks, but I won't press the issue.

Thanks,

-- 
    /kinkie