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 > > The first 3 patches are reposted with updates following discussion of the > option > syntax. With this patch I've decided to break entirely with the previous > syntax. > Given that option parsing was previously both broken and undocumented, this is > hopefully a forgivable sin. > > The new syntax is: > > http://user:passw...@example.com/path?query[opt1=val:opt2=val] > > I've bounded the option block in square brackets as these have no semantic > meaning in any of the supported URI formats.
Offhand, I'm not liking this. Why not use a completely valid URI, with '.../path?query&opt1=val&opt2=val'? Inventing your own [opt1=val:opt2=val] on top of URI is asking for confusion. 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? Is it something where you could use a local option named '.../path?query=foo=bar' that contains anything to pass on to the raw uri for curl as '.../path?foo=bar' (that is, ALL query name=value pairs are local, but you have a name of 'query' whose value can be the URI-encoded string to pass on as the name=value pairs for the raw URI that you are passing through)? That would be more consistent so that the option is an actual URI to begin with. > Consequently the user can escape > them if they're unfortunate enough to have a URI which looks like it contains > an > option block. > > I decided to separate options with colons rather than commas because commas > play > havoc with qemu's command line parsing. There's presumably a way round this, > but > I couldn't guess it and I was too lazy to look it up, so I assume users would > feel the same. Using ',,' behaves as an escape for any literal comma, when doing qemu command line option parsing. > > As options are now unambigous, invalid options now result in an error. > > [PATCH 4/4] curl: Fix build when curl_multi_socket_action isn't > > The last patch is unrelated. It should fix build against old curl, although I > don't have an old curl kicking around to test it against. > > I still have a couple of patches in my local tree which: > > * Remove blocking behaviour in curl_open > * Don't send EIO when a read connection hits a timeout > > I'm also planning to add another option for timeout length, and to implement > write support. > > Matt > > > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
