> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Thursday, 23 June 2022 18.43 > > This RFC shows one possible approach for escaping strings for the json > output of telemetry library. For now this RFC supports escaping strings > for the cases of returning a single string, or returning an array of > strings. Not done is escaping of strings in objs/dicts [see more below > on TODO]
Very good initiative. > > As well as telemetry lib changes, this patchset includes unit tests for > the above and also little bit of cleanup to the json tests. > > TODO: > Beyond what is here in this RFC: > > 1. we need to decide what to do about name/value pairs. Personally, I > think we should add the restriction to the "rte_tel_data_add_obj_*" > APIs > to only allow a defined subset of characters in names: e.g. > alphanumeric > chars, underscore and dash. That means that we only need to escape > the data part in the case of string returns. I agree about only allowing a subset of characters in names, so JSON (and other) encoding is not required. However, I think we should be less restrictive, and also allow characters commonly used for separation, indexing and wildcard, such as '/', '[', ']', and '*', '?' or '%'. Obviously, we should disallow characters requiring escaping in not just JSON, but also other foreseeable encodings and protocols. So please bring your crystal ball to the discussion. ;-) > 2. once agreed, need to implement a patch to escape strings in > dicts/objs Yes. > > 3. need to add a patch to escape the input command if it contains > invalid chars What do you mean here? You mean unescape JSON encoded input (arriving on the JSON telemetry socket) to a proper binary string? > 4. some small refactoring of the main telemetry.c json-encoding > function > may be possible. Perhaps.
