From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wfpjh-0007Cu-7r for qemu-devel@nongnu.org; Thu, 01 May 2014 08:05:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfpjR-0002Mp-Lh for qemu-devel@nongnu.org; Thu, 01 May 2014 08:05:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfpjR-0002Mf-E9 for qemu-devel@nongnu.org; Thu, 01 May 2014 08:04:53 -0400 Message-ID: <53623862.1050603@redhat.com> Date: Thu, 01 May 2014 06:04:50 -0600 From: Eric Blake MIME-Version: 1.0 References: <1398867658-2069-1-git-send-email-mbooth@redhat.com> <1398867658-2069-2-git-send-email-mbooth@redhat.com> <20140430151638.GE4380@noname.redhat.com> <53620C41.3040506@redhat.com> In-Reply-To: <53620C41.3040506@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="goKVFKtORqoK7Ec8F0VgGdRrr8b9Xjaex" Subject: Re: [Qemu-devel] [PATCH 1/3] curl: Fix parsing of readahead option from filename List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matthew Booth , Kevin Wolf Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --goKVFKtORqoK7Ec8F0VgGdRrr8b9Xjaex Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/01/2014 02:56 AM, Matthew Booth wrote: > On 30/04/14 16:16, Kevin Wolf wrote: >> Am 30.04.2014 um 16:20 hat Matthew Booth geschrieben: >>> curl_parse_filename wasn't removing the option string from the url, >>> resulting in a 404. >>> >=20 > Alternatively I could completely change the syntax. However, the only > 'safe' syntax I can think of would involve ugly custom escaping, which > would probably catch out more people than unsafe option parsing. I'm > open to suggestions. The name is a URI, so it should already be possible to use URI escaping (percent-hex-hex) for any character that must be interpreted as part of the filename rather than as a bogus query. Therefore, you should be strict and require that the user passes in a valid URI with all options known and with the filename spelled correctly using URI escapes, rather than loose and parsing what would otherwise be garbage as a possible weird filename. >=20 > On a related note, do you know if it's possible to specify a backing > file with separated options? i.e.: >=20 > qemu-img create -f qcow2 -o > backingfile.url=3D'http://example.com/path',backingfile.readahead=3D'64= k' > /tmp/foo.qcow2 It should be possible; in fact, if the backing file is supported in BlockdevOptions for the QMP blockdev-add command it already is. If it is not supported in BlockdevOptions, then we need structured options added to make it possible. But you can use any of the backing stores that are already structured as your example. >=20 > I suspect that qcow2 only stores a string, so probably not, but I > thought I'd ask. There's a proposal for a new json: protocol, which allows storing ANY arbitrary BlockdevOptions as a flat string in the qcow2 metadata (within the limits of the header format which forces you to 1024 bytes or less). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --goKVFKtORqoK7Ec8F0VgGdRrr8b9Xjaex Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTYjhiAAoJEKeha0olJ0NqjLoIAJTmaxWcQ1WDod3qUNk5yFgt DJFjmdfoXZXRGn4QebTJgRkOI+Z+wa/V8HC58QU5rKs0L/cGAG5XYWvaxq3B4614 hLL2LvG/NjhilVQm7qj2IRmmAqpR+0b2bL5hzR4bjwlZIwiorLxbSzgKuBLWbFni eTIAAX0ZY6zvSdwITyQmEdNiT09qs47vsAzx0aAN9GqGVLLBKTxZxV4ZkiycMhqp XNP3L4k5G4WBsd84HT6TYrRZTvDFh3Ja0B1MolXjCOUNzIo6JtbmMJEDb/NWZ2qQ AguRpX21MhMkjL6xbxm1uEnbeboaETDNsmkEEPMiYd4s5Q+gQazGJqCUh1yUy0o= =vuXz -----END PGP SIGNATURE----- --goKVFKtORqoK7Ec8F0VgGdRrr8b9Xjaex--