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.