On Tue, Aug 08, 2017 at 09:54:53AM -0700, Junio C Hamano wrote:
> > For comparison, nothing older than curl 7.19.4 will work for building
> > Git since v2.12.0, as we added some unconditional uses of CURLPROTO_*
> > there. Nobody seems to have noticed or complained. I pointed this out a
> > few mo
Jeff King writes:
> I think we're not quite ready to switch to curl based on comments in the
> nearby thread. But just for reference, since I started looking into
> this...
>
> The defines in the Makefile turn on USE_CURL_FOR_IMAP_SEND want curl
> 7.34.0. That's only from 2013, which is probably
On Sun, Aug 06, 2017 at 06:34:22PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > That is fine by me. AFAIK, we already build the curl support by default
> > when a sufficiently-advanced version of curl is available. So if there
> > were feature-parity problems hopefully somebody would h
On Sun, Aug 06, 2017 at 09:12:16PM +0200, Nicolas Morey-Chaisemartin wrote:
> Also it probably make sense to have at least one release where --curl
> is the default. Until your mail I had no idea this option existed so I
> never tried it out.
> Making it the default will make sure almost everyone
Jeff King writes:
> That is fine by me. AFAIK, we already build the curl support by default
> when a sufficiently-advanced version of curl is available. So if there
> were feature-parity problems hopefully somebody would have reported it.
>
> I think the deprecation here can be relatively fast be
Le 04/08/2017 à 23:22, Jeff King a écrit :
> On Fri, Aug 04, 2017 at 02:18:13PM -0700, Junio C Hamano wrote:
>
>>> I also think it might be reasonable to scrap all of this ad-hoc imap
>>> code in favor of curl, which already gets these cases right. We already
>>> have a curl-backed implementation.
On Fri, Aug 04, 2017 at 02:18:13PM -0700, Junio C Hamano wrote:
> > I also think it might be reasonable to scrap all of this ad-hoc imap
> > code in favor of curl, which already gets these cases right. We already
> > have a curl-backed implementation. I think we just left the old code out
> > of c
Jeff King writes:
> It's been a long time since I've done anything with IMAP, but I think
> another alternative would be to send it as a "literal", like:
>
> {6}
> foobar
>
> That's relatively easy to format correctly using the current printf
> specifiers that imap_exec() takes. Though as I s
On Fri, Aug 04, 2017 at 09:46:49PM +0200, Andreas Schwab wrote:
> > For example, FRC3501 "9. Formal Syntax" says that both "password"
> > and "userid" are "astring"; it looks strange that the code with this
> > patch only touches cred.password while sending cred.username as-is.
>
> astring
On Fri, Aug 04, 2017 at 08:06:43PM +, brian m. carlson wrote:
> On Fri, Aug 04, 2017 at 06:16:53PM +0200, Nicolas Morey-Chaisemartin wrote:
> > static struct imap_store *imap_open_store(struct imap_server_conf *srvc,
> > char *folder)
> > {
> > struct credential cred = CREDENTIAL_INIT;
On Fri, Aug 04, 2017 at 06:16:53PM +0200, Nicolas Morey-Chaisemartin wrote:
> static struct imap_store *imap_open_store(struct imap_server_conf *srvc,
> char *folder)
> {
> struct credential cred = CREDENTIAL_INIT;
> @@ -1090,7 +1116,7 @@ static struct imap_store *imap_open_store(struct
>
On Aug 04 2017, Junio C Hamano wrote:
> Is the quoting rules documented somewhere? If so, please also give
> a reference to it here. RFC3501 "6.2.3 LOGIN Command" does not say
> much (other parts of the RFC may specify the rules that apply to
> arguments in general, but I didn't look for them).
Le 04/08/2017 à 21:09, Junio C Hamano a écrit :
> Nicolas Morey-Chaisemartin writes:
>
>> Password containing backslashes need to have them doubled to have them
>> properly interpreted by the imap server.
> Please wrap this into lines with reasonable lengths like 72 cols.
I haven't checked the
Nicolas Morey-Chaisemartin writes:
> Password containing backslashes need to have them doubled to have them
> properly interpreted by the imap server.
Please wrap this into lines with reasonable lengths like 72 cols.
Is the quoting rules documented somewhere? If so, please also give
a referen
Password containing backslashes need to have them doubled to have them properly
interpreted by the imap server.
A password terminating with a blackslash used to trigger this error:
IMAP command 'LOGIN ' returned response (BAD) - Missing '"'
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-s
15 matches
Mail list logo
