From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: libvirt-users@redhat.com, Peter Luo <d8514@sina.com>,
QEMU <qemu-devel@nongnu.org>
Subject: Re: Does Libvirt's json parser support single quoted string in qmp json string?
Date: Tue, 04 Feb 2020 11:53:50 +0100 [thread overview]
Message-ID: <87tv467hdt.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200204092130.GA2205287@redhat.com> ("Daniel P. Berrangé"'s message of "Tue, 4 Feb 2020 09:21:30 +0000")
Daniel P. Berrangé <berrange@redhat.com> writes:
> On Tue, Feb 04, 2020 at 09:11:27AM +0100, Markus Armbruster wrote:
>> Eric Blake <eblake@redhat.com> writes:
>>
>> > [adding Markus]
>> >
>> > On 2/3/20 4:13 AM, Daniel P. Berrangé wrote:
>> >> On Fri, Jan 31, 2020 at 06:44:42AM -0600, Eric Blake wrote:
>> >>> On 1/31/20 4:38 AM, Peter Luo wrote:
>> >>>
>> >>>> error: internal error: cannot parse json {"execute": "block-commit", "arguments": { "device": "drive-virtio-disk2", "job-id": "job100", "base":'json:{"encrypt.key-secret":"vol-38973xjl.secret","driver":"qcow2","file":{"driver":"file","filename":"/pitrix/data/container/vol-38973xjl.img"}}', "top": "/pitrix/data/container/vol-38973xjl_ss-2tw7v0mm.img"}}: lexical error: invalid char in json text.
>> >>>>
>> >>>> , "job-id": "job100", "base":'json:{"encrypt.key-secret":"vo
>> >>>>
>> >>>> (right here) ------^
>> >>>>
>> >>>
>> >>> qemu's QMP language has an extension where it accepts 'string' in addition
>> >>> to the JSON "string". But it uses a hand-rolled parser, so it can do
>> >>> whatever it wants.
>> >>
>> >> Can we deprecate & remove this extension in QEMU ?
>
> [snip]
>
>> >> On the flip side, if we're going to support extensions like single quoting,
>> >> then we should make it clear to applications that this is not really JSON
>> >> and that they need to provide an impl that is 100% matching QEMU's dialect.
>> >> This effectively means they need just import a copy of QEMU's code.
>>
>> To the best of my knowledge, the JSON parser interprets any valid strict
>> JSON input in accordance to RFC 8259. In other words, you don't notice
>> the extensions unless you use them, or rely on invalid strict JSON to be
>> rejected.
>>
>> Peter Luo's input uses one of QEMU's JSON parser's extensions like this:
>>
>> "base":'json:{...}'
>>
>> This is not valid strict JSON. Libvirt's JSON parser doesn't accept it.
>>
>> The problem is not presence of extensions in QEMU, it's the use of these
>> extensions in input for libvirt. Removing the extensions from QEMU will
>> not affect the error. Removing their use from the input will.
>
> The issue that I see is that QEMU accepts this input string when it
> parsers JSON provided by the user. This in turn means the user has
> an expectation that other tools based on QEMU will accept this exact
> same document. This is not the case because the other tools are
> using a stricter impl of JSON.
>
> IOW QEMU's extensions have mislead the users into believing their
> JSON input is valid for any tool based on QEMU.
>
> Thus overall I think it would be beneficial for any places where
> QEMU accepts JSON from external users or apps, to be restricted to
> common JSON syntax only, without any QEMU specific extensions.
I don't think the JSON extensions are much of a problem. But I also
don't think they provide much value in the external interface. Feel
free to post patches that deprecate them there.
Aside: deprecating stuff in QMP is awkward, because we don't have a good
way to tell users. We do it anyway.
next prev parent reply other threads:[~2020-02-04 10:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ADDDD4B8-45AD-4D79-9332-06F2A50B26CE@sina.com>
[not found] ` <9bac386b-5a90-3c10-b63b-d45a2e8c2d58@redhat.com>
[not found] ` <20200203101352.GB1922177@redhat.com>
2020-02-03 16:27 ` Does Libvirt's json parser support single quoted string in qmp json string? Eric Blake
2020-02-04 8:11 ` Markus Armbruster
2020-02-04 9:21 ` Daniel P. Berrangé
2020-02-04 10:53 ` Markus Armbruster [this message]
2020-02-04 9:24 ` Daniel P. Berrangé
2020-02-05 0:09 ` John Snow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tv467hdt.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=d8514@sina.com \
--cc=libvirt-users@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.