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:39 UTC
- Message-ID
- <50fb321e-bbfc-adae-992d-eea1b818171e@suse.de>
- In-Reply-To
- <20171130020445.GF15098@aiede.mtv.corp.google.com>
Le 30/11/2017 à 03:04, Jonathan Nieder a écrit :
Show 46 quoted lines
> (+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. 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.
Nicolas