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.
[channel-ID] (OK/ERR/BH) [key-pairs] <blob> <terminator>
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?
With [key-pair] before any helper-specific <blob>, we can add a
key-pair "cert=<foo>" for generic certificate passing around if/when
necessary.
Do you want me to provide basic reusable classes for helper request
formatting and response parsing, if I have a chance?
I have one almost finished as a callback params object for replies.
As
soon as it passes all the build tests I'll be submitting a patch
before
starting to merge the parsers and extend the available response
key-pairs.
If you want to make a generic one for requests that would help. It's
a
bit more complicated to get backward compatible due to the larger
syntax
variance between helper request formats.
Understood.
Alex.
