From: Eric Blake <eblake@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
mbooth@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] curl: Allow a cookie or cookies to be sent with http/https requests.
Date: Fri, 29 Aug 2014 09:39:46 -0600 [thread overview]
Message-ID: <54009EC2.30107@redhat.com> (raw)
In-Reply-To: <20140829152848.GC1302@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
On 08/29/2014 09:28 AM, Richard W.M. Jones wrote:
> On Fri, Aug 29, 2014 at 09:10:10AM -0600, 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.
>>>
>>
>> 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"')?
>
> For my immediate needs, I don't care at all about multiple cookies.
> It's just a side-effect of the CURL API that they would work here.
> I'm happy to drop all references to them from the documentation ...
Okay, given that we are treating the string as an opaque passthrough to
keep curl happy, and not something we are processing internally, I'm
happy with keeping it as a single (long) string, and just simplifying
the docs to mention that it is a string for curl to use, perhaps without
needing to go into details on whether it allows one vs. multiple cookies.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]
next prev parent reply other threads:[~2014-08-29 15:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 15:03 [Qemu-devel] [PATCH v2] curl: Allow a cookie or cookies to be sent with http/https Richard W.M. Jones
2014-08-29 15:03 ` [Qemu-devel] [PATCH v2] curl: Allow a cookie or cookies to be sent with http/https requests Richard W.M. Jones
2014-08-29 15:06 ` Matthew Booth
2014-08-29 15:10 ` Eric Blake
2014-08-29 15:28 ` Richard W.M. Jones
2014-08-29 15:39 ` Eric Blake [this message]
2014-08-29 15:31 ` Matthew Booth
2014-08-29 15:11 ` [Qemu-devel] [PATCH v2] curl: Allow a cookie or cookies to be sent with http/https Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54009EC2.30107@redhat.com \
--to=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=mbooth@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).