From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkTvQ-00060k-US for qemu-devel@nongnu.org; Wed, 14 May 2014 03:48:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkTvK-0000zs-JJ for qemu-devel@nongnu.org; Wed, 14 May 2014 03:48:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkTvK-0000zo-9s for qemu-devel@nongnu.org; Wed, 14 May 2014 03:48:22 -0400 Date: Wed, 14 May 2014 09:48:17 +0200 From: Kevin Wolf Message-ID: <20140514074817.GB3610@noname.redhat.com> References: <1399538540-5076-1-git-send-email-mbooth@redhat.com> <537276C6.5010308@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: <537276C6.5010308@redhat.com> Subject: Re: [Qemu-devel] Curl updates List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: peter.maydell@linaro.org, Matthew Booth , qemu-devel@nongnu.org --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 13.05.2014 um 21:47 hat Eric Blake geschrieben: > On 05/08/2014 02:42 AM, Matthew Booth wrote: > > [PATCH 1/4] curl: Fix parsing of readahead option from filename > > [PATCH 2/4] curl: Add sslverify option > > [PATCH 3/4] curl: Add usage documentation > >=20 > > The first 3 patches are reposted with updates following discussion of t= he option > > syntax. With this patch I've decided to break entirely with the previou= s syntax. > > Given that option parsing was previously both broken and undocumented, = this is > > hopefully a forgivable sin. > >=20 > > The new syntax is: > >=20 > > http://user:password@example.com/path?query[opt1=3Dval:opt2=3Dval] > >=20 > > I've bounded the option block in square brackets as these have no seman= tic > > meaning in any of the supported URI formats. >=20 > Offhand, I'm not liking this. Why not use a completely valid URI, with > '.../path?query&opt1=3Dval&opt2=3Dval'? Inventing your own > [opt1=3Dval:opt2=3Dval] on top of URI is asking for confusion. >=20 > Are you trying to support a way to pass a query string to the curl URI, > in addition to local options? How often do curl URIs need a query? My guess would be that you need this more often than local options. Anyway, let's not add new options encoded in the URL, but point users to separate options. We may decide that we need the support the old crude way of encoding local options for compatibility, but preferably I would make filename just a plain URL. Kevin --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTcx/BAAoJEH8JsnLIjy/W42gP/2fLFmLN50ML8cKh/uBg006U s1HjJ8P1OAAMoIGgd+dXy0EydENQDxRpbho8HOJT9qhJJo5+WiubnMQ6oInKbuLC rgATmPzaRkxht1OuVrApD2LNRHRTvvIr/lZthy3reqNTLBY+IqeXs3KB+B9cr2Hl a0UniS3zqNwr0t4HCgN+mOzIIAtFCAO0dyRBJb8EVlUUh+HtQ+fxbBucMxA3qTOE WK1nwwYe+wAzD5MNncnSxMVz1a4CSPS5rrMPUweyyXhmU5dP7xpN7hC9GOqxPNdw p6OrFmPqlUSjtGOMfnWCTe1vCU++Su2v+LbUb83su4Vkwp25aVvwdw4V9f9LSmBn MjsS3WDN8D+8yENaDnmVis5VF/kXz86pK++PksQDJjfy87vcoravECbaKT8xBhaP /croDsJa9iOP+J0sIQs5QQQEXdFsr6C+93v3TLNQe2CSCZ8+ZgAbzbqfPxVrZzWM IczOyu1zmP9M9qGrobMiON6JmdFNeyXEroQ0GJfWMXxbodpyirhHv+9Nb01T+VvG fmR79QGvIHpB4G4XDweR62ya2QJ8S0m1KhK2MydgTrXTY6+UHKFLz4xRxtODhK1h 0eNiz6ZUundWOTtWYIC60+fKdRPhUOYS4EFDjEsdhMCJZYsVwctkHeXXOTnbvuLB WvC2FRuM1PgE0hR4GO3l =BE5W -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1--