Re: [Qemu-devel] Curl updates

[Matthew Booth <mbooth@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/05/14 15:47, Eric Blake wrote:
> 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:password@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.

The curse of replying without reading all outstanding responses :) I
think I answered this in my previous reply.

A URI can, by definition, contain a query string, and we cannot assume
that it won't. In fact, the use case I'm specifically interested in
always includes a query string. If we try to overload the query
string, we're adding heuristic fuzziness. My syntax makes the option
string distinct from the URI, so no heuristics are required. It's also
very clear to read IMHO.

Matt

> 
>> 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
>> 
>> 
>> 
> 


- -- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNzlHUACgkQNEHqGdM8NJAJBgCeK8+XmnVN/p0DFKyhiM0A/+RD
6yQAoJqUfJ6JrGhKT7Nv8HhLAeVstxyz
=91Eb
-----END PGP SIGNATURE-----