Re: imap-send with gmail: curl_easy_perform() failed: URL using bad/illegal format or missing URL

From: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.de>
Date: Nov 30, 2017, 09:47 UTC
Message-ID: <6b1b1c11-cf17-35e8-1d33-42102d9526ea@suse.de>
In-Reply-To: <50fb321e-bbfc-adae-992d-eea1b818171e@suse.de>

Le 30/11/2017 à 10:39, Nicolas Morey-Chaisemartin a écrit :

Show 55 quoted lines

>
> Le 30/11/2017 à 03:04, Jonathan Nieder a écrit :
>> (+cc: Nicolas)
>> Hi,
>>
>> Doron Behar wrote:
>>
>>> I'm trying to send a patch with the command `git imap-send`, I used the
>>> examples in the manual page as the main reference for my configuration:
>>>
>>> ```
>>> [imap]
>>> 	folder = "[Gmail]/Drafts"
>>> 	host = imaps://imap.gmail.com
>>> 	user = doron.behar@gmail.com
>>> 	port = 993
>>> 	sslverify = false
>>> ```
>>>
>>> This is my `cat patch.out | git imap-send` output:
>>>
>>> ```
>>> Password for 'imaps://doron.behar@gmail.com@imap.gmail.com':
>>> sending 3 messages
>>> curl_easy_perform() failed: URL using bad/illegal format or missing URL
>>> ```
>> Thanks for reporting this.  I suspect this is related to
>> v2.15.0-rc0~63^2 (imap-send: use curl by default when possible,
>> 2017-09-14) --- e.g. perhaps our custom IMAP code was doing some
>> escaping on the username that libcurl does not do.
>>
>> "man git imap-send" says this is a recommended configuration, so I
>> don't think it's a configuration error.
>>
>> What platform are you on?  What version of libcurl are you using?
>>
>> In libcurl::lib/easy.c I am also seeing
>>
>>     if(mcode)
>>       return CURLE_URL_MALFORMAT; /* TODO: return a proper error! */
>>
>> which looks suspicious.
>>
>> Nicolas, am I on the right track?
>>
>> Thanks,
>> Jonathan
>>
> This is due to the weird "[Gmail]" prefix in the folder.
> I tried manually replacing it with:
>         folder = %5BGmail%5D/Drafts
> in .git/config and it works.
>
> curl is doing some fancy handling with brackets and braces. It make sense for multiple FTP downloads like ftp://ftp.numericals.com/file[1-100].txt, not in our case.
> The curl command line has a --globoff argument to disable this "regexp" support and it seems to fix the gmail case.

In fact no, StackOverflow was wrong :)

> However I couldn't find a way to change this value through the API...
>
> I guess we should open a bug upstream to get access to this setting through the API and add a patch that HTTP encode brackets and braces in the meantime.
>

This means with have to URI encode the folder. DO we have a helper for that ?

Nicolas