From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9D1E7A0032; Fri, 24 Jun 2022 13:16:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7F96C4069D; Fri, 24 Jun 2022 13:16:48 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 16749400EF for ; Fri, 24 Jun 2022 13:16:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656069407; x=1687605407; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=l2+9tuVxyuF7zNXlLfDxqzSeyqas7afiuEDxHGW19Is=; b=Rg8Kzl8U1CX1oLwSxGkwvsZS4clQunnfGcjstNx5k/NLb1qcVdFqz/NK ue7FdRJcMJw3oaW4rrAGfLkhz+27407n8tztD5skxm+H+auHn2xJBnZnR ItZQd4PY6Q6QjAOWPYWH0hG7SuV6Rrv/YnE5C8tRKK5qgT25yEd7fuc2Z G/9iBsbvA3WI2xvz+CbvmRemrcWuUHA9TTXlPTCpza2N/F6Aym0YCt/PS EVCmnVbbY0CQbIUKGuYXCZfvGjNkThW2DzHgLe5t4GvANuqS5r5W2zS8D 7Xkhd3TZeFRcAprVsr5xR/gc2RMNIB30bnhzNnA8jSUnRbo+cH9xJl8bn w==; X-IronPort-AV: E=McAfee;i="6400,9594,10387"; a="281714546" X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="281714546" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 04:16:46 -0700 X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="656608884" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.25.171]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 24 Jun 2022 04:16:44 -0700 Date: Fri, 24 Jun 2022 12:16:41 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Stephen Hemminger , dev@dpdk.org, ciara.power@intel.com, fengchengwen@huawei.com Subject: Re: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters Message-ID: References: <20220623164245.561371-1-bruce.richardson@intel.com> <20220623164245.561371-3-bruce.richardson@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D8716B@smartserver.smartshare.dk> <20220623113934.372b059e@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35D8716C@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 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.