On 29/08/14 16:10, Eric Blake wrote:
> On 08/29/2014 09:03 AM, Richard W.M. Jones wrote:
>> In order to access VMware ESX efficiently, we need to send a session
>> cookie. This patch is very simple and just allows you to send that
>> session cookie. It punts on the question of how you get the session
>> cookie in the first place, but in practice you can just run a `curl'
>> command against the server and extract the cookie that way.
>>
>
>> +++ b/qemu-options.hx
>> @@ -2351,6 +2351,11 @@ multiple of 512 bytes. It defaults to 256k.
>> @item sslverify
>> Whether to verify the remote server's certificate when connecting over SSL.
>> It
>> can have the value 'on' or 'off'. It defaults to 'on'.
>> +
>> +@item cookie
>> +Send this cookie (it can also be a list of cookies separated by ';') with
>> +each outgoing request. Only supported when using protocols such as HTTP
>> +which support cookies, otherwise ignored.
>
> ';' has to be quoted to enter it in the shell command line (but then
> again, the cookie probably contains literal " which also has to be quoted).
>
> We still don't have a QMP mapping for curl device hotplug. But when we
> gain one, do we really want to have a single (long) string containing
> multiple cookies, or would it be better to make this an array argument?
> On the command-line, which is nicer, taking the cookie option multiple
> times ('file.cookie=xyz,file.cookie.abc'), taking it as an automatic
> array ('file.cookie.0=xyz,file.cookie.1=abc') or forcing the user to
> cram all cookies into a single option ('file.cookie="xyz;abc"')?
I thought about this, too. We're really only passing on curl's cookie
syntax:
http://curl.haxx.se/libcurl/c/CURLOPT_COOKIE.html
So even if we did it differently, the driver would still have to
reconstruct this string with ';' separation and handle escaping issues.
I doubt this will be a commonly used option, and even less frequently
used with multiple cookies, if ever[1]. Given that it is possible to use
multiple cookies without massive effort, I think the substantially
simpler code is a reasonable trade-off.
Matt
[1] Feel free to lart me with this at a later date ;)
--
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
