On 04.07.2012 13:07, Alex Rousskov wrote:
On 07/03/2012 06:54 PM, Amos Jeffries wrote:
On 04.07.2012 12:11, Alex Rousskov wrote:
On 07/03/2012 04:56 PM, Amos Jeffries wrote:
On 03.07.2012 14:59, Alex Rousskov wrote:
On 07/02/2012 06:20 PM, Amos Jeffries wrote:
I am in the process of modifying the helper API for consistency
across
all helpers starting with 3.3. It would be great if you could
design
your helper to use a generic output format for data sent back to
Squid:
[channel-ID] (OK/ERR/BH) [key-pairs] <terminator>
OK, but not all helper communication is line-based. We may need
to send
PEM-encoded certificates back (and ssl_crtd already does that).
That
requires sending multiline blocks of data.
If you want to generalize that, consider adding body start/end
terminators.
I know. That is why I omit the word "line" and specify
<terminator>
instead of <EOL>.
The proposed format is missing the body itself, unless you want to
force
all helpers to use key=value format for blobs such as PEM-encoded
certificates.
Oops. yes. The HelperReply object has to include a field <blob> of
type
char* specific to each helper (for certs and bodies blobs, messages,
etc.) which includes everything between the first undentifiable
key-pair
and the terminator. It is required for backward compatibility even
if I
was set on key-pair always. So it may as well be formalised.
Why should the body include key-value pairs?
Huh? which body are you referring to now?
[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.
In that sense it is not completely "generic", but more cross-helper
shared key-pairs being accepted back without barfing. Some will of
course be accepted but unused by certain helpers handler code (ie a
url=FOO from authenticators).
NOTE:
Existing code has a shared parser pulling off [channel-ID] and passing
the remainder as char* to the helpers callback.
What I'm doing in patch-#1 is making that shared parser pathway also
handle the OK/ERR/... result field shared by almost all the helpers
(redirectors exception) and converting the char* callback parameter to
an object (result, <blob>). 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.
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.
Ideally, there will be a way for generic helper parsers to
detect and extract the body. To reach that ideal, there should be a
common format that includes the body.
Yes.
Pedant: There are only 2 helpers out of 14 that send certificate
bodies.
This new one and ssl_crtd. Why define a "body" field just for them?
It is certainly not needed if you do not want to have one
parser/format
for all helpers. We can continue to craft custom code for each new
helper that needs to send bodies if you think that is the best
approach.
Um, we seem to be getting off on different paths.
I *do* want a shared parser for as many details as possible ideally all
details as key-pair. I'm asking why you want a special field locking one
position in just for certificate body?
Defining a "foo=" key would possibly be useful. Even a custom value
micro-format for that key-pair. The key-pairs are ALL optional when
overall cross-helper needs are considered.
With [key-pair] before any helper-specific <blob>, we can add a
key-pair
"cert=<foo>" for generic certificate passing around if/when
necessary.
This approach does not work well because <foo> may include spaces/'='
and, hence, be confused with more key-pairs.
We are going to have to create a generic parser for HTTP header
field-values with this same syntax of key-pairs. With quoted-string and
url-encoding already requirements on some helpers re-using the same
parser routine to output key-pair and field-value is not going to be an
issue.
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.
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?
Amos
