Re: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Jun 24, 2022 at 09:00:38AM +0100, Bruce Richardson wrote:
> On Thu, Jun 23, 2022 at 08:48:21PM +0200, Morten Brørup wrote:
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Thursday, 23 June 2022 20.40
> > > 
> > > On Thu, 23 Jun 2022 20:34:07 +0200
> > > Morten Brørup <mb@smartsharesystems.com> wrote:
> > > 
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Thursday, 23 June 2022 18.43
> > > > >
> > > > > For string values returned from telemetry, escape any values that
> > > > > cannot
> > > > > normally appear in a json string. According to the json spec[1],
> > > the
> > > > > characters than need to be handled are control chars (char value <
> > > > > 0x20)
> > > > > and '"' and '\' characters.
> > > >
> > > > Correct. Other chars are optional to escape.
> > > 
> > > For json_writer (which I wrote for iproute2 and could have been used
> > > here).
> > > The switch handles: \t \n \r \f \b \\ " ' as special cases.
> > 
> > RFC 8259 chapter 7 says:
> > 
> >    All Unicode characters may be placed within the
> >    quotation marks, except for the characters that MUST be escaped:
> >    quotation mark, reverse solidus, and the control characters (U+0000
> >    through U+001F).
> > 
> > I have no preference for either, as long as '/' and other non-control characters are not (unnecessarily) escaped.
> > 
> > Using tested and maintained code like json_writer could be beneficial. If you hold the copyright, there should be no license issues.
> > 
> 
> I will take a look at json_writer.

Took a quick look at json_writer, and it's certainly an option. The main
gap compared to what we have in our current implementation is that
json_writer is designed around a stream for output rather than an output
buffer. Now while we can use fmemopen to make our buffer act as a stream
for writing, and the write apis should prevent it overflowing, we still hit
the issue of the result of truncation not being valid json. The current
implementation tries to handle truncation more gracefully in that any
fields which don't fit just don't get added.

I'll think about it a bit more, and see if there is a way that it can be
made to work more cleanly.

/Bruce

PS: just changing the output from a string to a stream on the output socket
I don't believe is an option either, as the socket type used for telemetry
is a SOCK_SEQPACKET where message boundaries are preserved, and a single
read will return the entire telemetry reply.