On Mon, Mar 5, 2018 at 8:37 PM, Willy Tarreau <w...@1wt.eu> wrote:
> Quotes could be part of some future statements and we'd
> possibly regret having used them if already used for this. For example we
> imagine one day uploading some JSON parts for certain things.
True, but it could also be addressed by switching the input mode to a
certain flavour (JSON, XML, whatever) but it is also true that
handling multiple lines also solves the problem and does not require
> 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 ?
Even if it can be present but optional, an empty line would still
signal the end of 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 ?
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).
> E.g. we could write (just using maps as a simple example) :
> add map foo.txt foo1 bar1
> add map foo.txt
> foo1 bar1
> foo2 bar2
> For OCSP, we could have :
> set ssl ocsp-response line1
> or :
> set ssl ocsp-response line1 line2 line3 line4===
> or :
> set ssl ocsp-response
Is there an advantage to allow these two syntaxes versus always the
one in  ? Why not always requiring an empty line if multi-line is
used ? That would still require cooperation from the handlers but it
will stay simple: do I have enough data to proceed ?
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
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.
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.