On 07/03/2012 08:10 PM, Amos Jeffries wrote:
>>> [channel-ID] (OK/ERR/BH) [key-pairs] <blob> <terminator>
>>
>> How will the generic code be able to tell where key-pairs end and blob
>> begins?
>
> The generic code will have a format for key-pair of ( 1#token "="
> 1#(token / quoted-string) ) [to be finalized still] with a set of known
> key names. If the bytes being parsed do not match that format and keys
> its not part of the key-pairs.
There are two problems with this approach, IMO:
* It cannot handle a body that just happened to start with supported
key-value pair characters.
* It cannot detect a case of helper sending unsupported key-value
pairs (if that helper may send a body too).
It also requires extra code/work to pre-register all known key names,
but that is minor.
> Some issues being resolved around char* vs
> String vs MemBuf (vs Sbuf?) for blob. Sort of settling on MemBuf for the
> ssl_crtd \0 handling requirements.
I agree that we should use MemBuf for this.
> The plan for patch-#2 is to discuss key-pair syntax (which we seem to
> have started), and move some particular key-pair parsing from helper
> handlers into the shared one. Opening up user=, tag=, password=, log=,
> message= keys to non-ACL helper responses will be VERY useful for RADIUS
> and systems needing to maintain cross-helper request state.
I think we should keep it as simple as possible without causing problems
with existing parsers and leaving some room for future extensions:
* key/name: alphanumeric char followed by anything except (whitespace or
'=' or terminator)
* value: either quoted-string or anything except (whitespace or
terminator); could be empty
The parser strips whitespace and strips quotes around quoted strings.
Quoted strings use backslash to escape any octet.
>> If you want one format for all, you probably need something like
>>
>> [channel-ID] (OK/ERR/BH) [key-pairs] [BS <body>] <terminator>
>>
>> where "BS" is some special marker that starts all bodies and cannot be
>> found in key-pairs. Since any body-carrying message is likely to have
>> new lines (and, hence, would need a non-newline terminator), this BS
>> sequence could be something like "body:\n", I guess.
>
> We REQUIRE a format that does not rely on new special markers like that
> in order to cope with the existing helpers responses in a
> backward-compatible way without additional user configuration.
When your parser sees "n=v " after ERR and "n" is a known key name, how
would it distinguish these two possibilities:
* This is a start of a <blob>
* This is a key=value pair
> Or would you advocate moving the external_acl_type "protocol=N.N" config
> option into the helper child object for use by all helpers on
> determining what key-pairs and format is accepted?
I am probably missing some important use cases, but my generic parser
would just call a virtual method for each key=value pair found (with no
pre-registration of supported keys) and another virtual method for the
<body> blob, if any. It will parse everything using the key, value, and
BS formats discussed above.
HTH,
Alex.
Received on Wed Jul 04 2012 - 04:54:53 MDT
This archive was generated by hypermail 2.2.0 : Wed Jul 04 2012 - 12:00:03 MDT