[gnutls-devel] inline command support in gnutls-cli

[Raj Raman]

Hi Nikos,

The inline commands being invoked from gnutls-cli, as currently
implemented, will be consumed at the client by the gnutls cli parser and
subsequent action will be performed by the client. These inline commands
will not be forwarded to the server. Given that these inline commands are
consumed locally at the client invoking the gnutls-cli, I am not sure I
fully understand your concern w.r.t server.

If your concern is that having inline commands like ^resume^ or
^renegotiate^ can lead to confusion as this functionality/command could
exist in the server as well, I could change ^resume^ and ^renegotiate^ to
^client-resume^ and ^client-renegotiate^ respectively. If you think we
should have flexibility in using a prefix, via an additional parameter,
instead of hard-coding ^, I can definitely look into adding this.

I will wait for your feedback. Sorry if I misunderstood your point.

Thanks
Raj

PS: copying comments from an earlier email to provide more context to
others.
* The inline commands is a facility that can be used optionally
* when --inline-commands is set during invocation of gnutls-cli
* to send inline commands at any time while a secure connection
* between the client and server is active. This is especially
* useful when the HTTPS connection is (HTTP) persistent -
* inline commands can be issued between HTTP requests, ex: GET.
* session renegotiation and session resumption can be issued
* inline between GET requests.
*
* Following inline commands are currently supported:
* ^resume^ - perform session resumption (similar to option -r)
* ^renegotiate^ - perform session renegotiation (similar to option -e)



On Sun, Sep 22, 2013 at 2:12 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On 09/19/2013 07:09 PM, Raj Raman wrote:
> > Hi Nikos,
> >
> > I would like to add infrastructure support in gnutls-cli for it to
> support
> > inline commands. The comments in the file inline_cmds.h (below) describes
> > this facility. We found this especially useful to test session resumption
> > and session renegotiation with HTTPS servers (or MITM devices) that
> support
> > HTTP persistence, since a single secure connection can support multiple
> > HTTP requests. The implementation makes no assumptions on contextual
> > boundary of TCP data. The existing behavior of command line options ‘-r’
> > and ‘-e’ remains unchanged. Please find the relevant description and
> patch
> > in the attachment.
>
> Hello Raj,
>  Thank you, the idea looks nice. What I am concerned is whether the
> commands used for cli are meaningful in some server. Would it make sense
> to have an additional parameter to specify an alternative prefix for the
> commands?
>
> regards,
> Nikos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130923/e1013c4a/attachment.html>