Re: [Qemu-devel] [Qemu-block] [PATCH v2] qemu-img / curl: When fetching Content-Size use GET instead of HEAD.

[John Snow]

On 12/09/2015 05:37 PM, Boris Schrijver wrote:
> Dear all,
> 
> Thanks for your time so-far.
> 
> I send a mail to the libcurl development list and got a helpful reaction [1]! 
> I
> changed my patch accordingly. We now don't have to check for a 
> CURLE_WRITE_ERROR
> anymore and curl_easy_perform() will return CURLE_OK (0) on success.
> 
> Please review!
> 

I apologize in advance for being pedantic, but if the patch is in the
wrong format, maintainers may not even notice the patches due to their
filtering systems. To make sure the right people see it, please follow
the advice below.

This is unnecessary stuff before the patch, which is serving as your
cover letter. Cover letters should either be sent separately as a "0/n"
patch email, or for single patch series (like this one), meta-commentary
should be included below the commit message, underneath the first "---"
line.

You can provide a --cover-letter argument to "git format-patch" to have
it generate a template cover letter for you if this is convenient.

Some people generate a cover letter for even single patch series; it's a
matter of taste/preference for where you want to include your commentary
if you have any to send.

> commit c5588e94f5f0e66636b16a4ee26f0dbcf48b44c9
> Author: Boris Schrijver <address@hidden>
> Date:   Wed Dec 9 23:32:36 2015 +0100
> 

Wrong patch format; it looks like you've done "git show > qemu.patch".
The header should look like this:


>From c5588e94...xxx... Mon Sep 17 00:00:00 2001
From: Joe Developer <address@hidden>
Date: Tue, 8 Dec 2015 16:00:11 -0500
Subject: [PATCH v3] component: subject

Brief summary

Additional explanation

Signed-off-by: Joe Developer <address@hidden>
Reviewed-by: Chris Reviewer <address@hidden>


---
V3: Improvements over V2:
 - blah
 - blah

V2:
 - blah

Please review, thank you!
---
 tests/example.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/tests/example.c b/tests/example.c
index 0888506..f4945dc 100644
--- a/tests/ahci-test.c

[etc etc etc.]

You can be sure it will be in a proper format if you:

git format-patch origin/master
git send-email address@hidden address@hidden
address@hidden --subject-prefix="PATCH v3"
0001-qemu-img-curl-use-get.patch

You can edit the .patch file before sending it to include any changelog
notes below the "---" line to separate it from your commit message,
before the git diff sections.

>     qemu-img / curl: When fetching Content-Size use GET instead of HEAD.
>     
>     A server can respond different to both methods, or can block one of the 
> two.
>     
>     Signed-off-by: Boris Schrijver <address@hidden>
> 
> diff --git a/block/curl.c b/block/curl.c
> index 8994182..1677d0c 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -598,6 +598,7 @@ static int curl_open(BlockDriverState *bs, QDict *options,
> int flags,
>      curl_easy_setopt(state->curl, CURLOPT_HEADERFUNCTION,
>                       curl_header_cb);
>      curl_easy_setopt(state->curl, CURLOPT_HEADERDATA, s);
> +    curl_easy_setopt(state->curl, CURLOPT_CUSTOMREQUEST, "GET");

I see. so curl thinks it is doing a HEAD request, but we trick it into
asking for GET instead. and since we clean up the context right away,
this should be harmless.

Much cleaner than the first attempt. Looks OK to me. When you re-spin
your patch, you may add:

Reviewed-by: John Snow <address@hidden>

to the commit message.

>      if (curl_easy_perform(state->curl))
>          goto out;
>      curl_easy_getinfo(state->curl, CURLINFO_CONTENT_LENGTH_DOWNLOAD, &d);
> 

---

You don't need to include reply data in patch emails.

> 
> 
> [1] http://curl.haxx.se/mail/lib-2015-12/0041.html
> 
> -- 
> 
> Met vriendelijke groet / Kind regards,
> 
> Boris Schrijver
> 
> PCextreme B.V.
> 
> http://www.pcextreme.nl/contact
> Tel direct: +31 (0) 118 700 215
> 
>> On December 8, 2015 at 8:56 PM Michael Tokarev <address@hidden> wrote:
>>
>>
>> 08.12.2015 00:23, Boris Schrijver wrote:
>> []
>>> It's is therefore better to use only the GET request method, and discard the
>>> body at the first call.
>>
>> Nooooooo!  Please NOOOO!
>>
>> Fetching a large file once might be too long already.
>> Fetching it twice is twice as long.  Oh well!..
>>
>> Thanks,
>>
>> /mjt
> 

Thanks!