Hello Aurélien,

On Tue, Mar 06, 2018 at 02:13:31PM +0100, Aurélien Nephtali wrote:
> > Probably that we could in fact extend the CLI syntax in a backwards 
> > compatible
> > way :
> >
> >    <word>[ <word>]* <arguments>*
> >    [optional body]
> >
> > Most commands don't use a body. Those using a body have to terminate it 
> > using
> > either its own representation known by the command, or an empty line.
> Wouldn't it be easier/clearer to always require an empty line if there
> is a body ?

In theory I fully agree. The only thing is that I'm uncertain about the
format used by OCSP right now. I think it starts as an argument, I'm not
certain whether or not it continues on multiple lines or not.

> Even if it can be present but optional, an empty line would still
> signal the end of it.

If that doesn't break OCSP, I'm all in favor of this, at least for the
sake of avoiding layering violation : the CLI layer transports the body
without having to understand it and it's only the consumer which decides
if it's complete or not while decoding it.

> > "set ssl ocsp-response" takes a series of words in arguments, or a body.
> > Some commands might even simply support the concatenation of both, ie they
> > start immediately on the argument, detect the block is not completed, and
> > read the rest on the following lines till the end is found (either defined
> > by the data format or by the empty line). This simplifies the syntax of
> > long commands, to support both the first line as the first series of
> > arguments, or as the first line of the body.
> Basically, it boils down to adding multi-lines support to the CLI, right ?

Looks like this indeed.

> The parser will have to be modified to wait until a keyword handler
> says it is ready to process the command if it has every argument it
> needs (continue) or some are missing (fail).

More or less. I'd rather return a 3rd case, like with do with samples :
"not sure yet" (need more data to decide). That allows the failure and
success cases to remain definitive.

> > E.g. we could write (just using maps as a simple example) :
> >
> >    add map foo.txt foo1 bar1
> >
> > or:
> >
> >    add map foo.txt
> >    foo1 bar1
> >    foo2 bar2
> >    LF
> [1]
> >
> > For OCSP, we could have :
> >
> >    set ssl ocsp-response line1
> >    line2
> >    line3
> >    line4===
> >
> > or :
> >    set ssl ocsp-response line1 line2 line3 line4===
> >
> > or :
> >    set ssl ocsp-response
> >    line1
> >    line2
> >    line3
> >    line4===
> Is there an advantage to allow these two syntaxes versus always the
> one in [1] ? Why not always requiring an empty line if multi-line is
> used ?

I just don't know exactly what is *currently* used. And we make it a
hard rule not to break existing deployments on purpose. People write
management scripts, utilities etc and purposely breaking their API is
really not fun at all. This is the *only* reason here. However since
I'm not sure about the current OCSP syntax, anything which still works
will be fine. For example, if it supports words passed as arguments
and doesn't use any extra line, we can simply make it accept either
an OCSP response passed as arguments, in which case there is no body,
or no argument at all in which case a body is expected, and terminated
by the empty line.

> That would still require cooperation from the handlers but it
> will stay simple: do I have enough data to proceed ?

That's why the "need more info" feedback from the handlers is needed,
and why (if possible), avoiding having to feed unterminated bodies to
these handlers "just in case" is better. Now that I'm thinking about
it, I don't see how the OCSP would currently consume extra lines, so
maybe it only works using arguments and we're already fine.

> In the case of ocsp-response, without an empty line, it would mean
> trying to decode the whole buffer at each new data - or maybe just
> what was added if base64dec() is modified to support partial data.
> Waiting for an empty line would simplify the logic by only decoding
> the buffer once - this is an example for ocsp-response but I think
> processing arguments once is easier than processing them at each new
> data.

I wholeheartly agree as long as we don't break existing ones ;-)
I'm even fine with not documenting the deprecated behaviours and only
document the new one to encourage migration.

> Requiring an empty line would also solve the case of commands with an
> unknown number of arguments. I do not know if there are some yet but
> they could then safely be added.

Indeed, like what I proposed for maps/acls.

> In the particular case of a PEM certificate, the handler would wait
> for an empty line and it would know it can treat what is after the
> known arguments as being the certificate without trying to guess it is
> complete - in the case where there would be no empty line.


I think we're in sync on this. Please take a look at OCSP to see how it's
currently handled so that we don't have to imagine all possibly stupid
cases. Also take a look at {set|add} {acl|map} and I think that should
be all for now to get the whole picture of the compatiblity we have to


Reply via email to