Re: Generic helper I/O format

On 05.07.2012 10:15, Alex Rousskov wrote:
> On 07/04/2012 02:34 PM, Henrik Nordström wrote:
>> ons 2012-07-04 klockan 13:02 -0600 skrev Alex Rousskov:
>
>> Why not simply use key=value pairs across the board?
>
> We need blobs because some values in use today are not expressed as
> tokens or quoted strings (the two value formats Amos is considering).
>
> We could, of course, _encode_ those inconvenient values so that
> things
> like SSL certificates can be represented as huge quoted strings. Is
> that
> what you are getting at? I am not against that, even though I am a
> little worried about the added encoding overhead. This will require
> changing ssl_crtd helper code, but I do not think that would be a big
> problem.
>
>
>
>>> 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.
>
> We are talking about a general format, not NTLM-specific format. Blob
> is
> optional. If NTLM helper does not need it, it will not use it.
>
>
>> 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).
>
> Yes, anonymous values or valueless names can be allowed if it helps
> existing helpers. Can somebody paste a typical NTLM helper response
> or two?
>

http://wiki.squid-cache.org/Features/AddonHelpers#Negotiate_and_NTLM_Scheme

If you note, the <reason> field is usually something other than OK/ERR,
so we can parse the old syntax differently to the new OK/ERR responses.

Where there is an overlap (BH) the <reason> field is an error message,
usually the program name and a ':' colon (not valid in the proposed
key-name) or number in brackets (again not valid in key name) or plain
text message (no '=' expected on human-readable words).

Amos
Received on Wed Jul 04 2012 - 23:07:28 MDT