GNU bug report logs - #23620
25.0.94; url-retrieve fails on localhost

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23620 in the body.
You can then email your comments to 23620 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.94; url-retrieve fails on localhost
Date: Wed, 25 May 2016 15:45:14 -0300

Assuming you have a webserver serving on localhost:5100, run the
following snippet:

(url-retrieve "http://localhost:5100/"
              (lambda (&rest r)
                (message "%S" r)))

It fails with the following error:
    (:error (error connection-failed "failed with code 111\n"
                   :host "localhost"
                   :service 5100))

Note that if I switch to a terminal and try curl:
    curl "http://localhost:5100/"
it works fine.

Using `url-retrieve' on remote urls also works fine.

Message #8 received at 23620 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Artur Malabarba <bruce.connor.am <at> gmail.com>
Cc: 23620 <at> debbugs.gnu.org
Subject: Re: 25.0.94; url-retrieve fails on localhost
Date: Sat, 28 May 2016 09:42:17 -0700

I'm not observing this problem on my platform (Fedora 23 x86-64, local web 
server is sthttpd).

I do see the problem if I attempt to connect to a non-webserver attached to a 
local TCP port (in my case, port 943 attached to sshd); perhaps your webserver 
isn't set up properly? But that situation looks like Bug#20159, i.e., user error 
not a bug in url-retrieve. Its callbacks are supposed to check status, not 
merely call 'message' willy-nilly.

Message #11 received at 23620 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23620 <at> debbugs.gnu.org
Subject: Re: 25.0.94; url-retrieve fails on localhost
Date: Wed, 01 Jun 2016 11:55:27 -0300

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> I'm not observing this problem on my platform (Fedora 23 x86-64, local
> web server is sthttpd).
>[...]
> perhaps your webserver isn't set up properly?

Indeed, I just tested with a different server project I have here and
there was no problem, so it seems to be specific to how this server is
configured.

However, I wouldn't go as far as to say the server is MISconfigured.
Like I said, it works fine with curl, wget, webrowsers, and any other
means I tried. Only url-retrieve failed on it.
Does anyone know how we could look further into it?

> I do see the problem if I attempt to connect to a non-webserver
> attached to a local TCP port (in my case, port 943 attached to sshd);

In my case it's just a rails server started with:
    bundle exec rails server -p 5100

> But that situation looks like Bug#20159, i.e., user error not a bug in
> url-retrieve. Its callbacks are supposed to check status, not merely
> call 'message' willy-nilly.

I used that callback simply to point out the 111 error code. The problem
here is that the request the fails, not how the user handles the failure.

Message #14 received at 23620 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Artur Malabarba <bruce.connor.am <at> gmail.com>
Cc: 23620 <at> debbugs.gnu.org
Subject: Re: 25.0.94; url-retrieve fails on localhost
Date: Wed, 1 Jun 2016 09:43:13 -0700

On 06/01/2016 07:55 AM, Artur Malabarba wrote:
>> >I do see the problem if I attempt to connect to a non-webserver
>> >attached to a local TCP port (in my case, port 943 attached to sshd);
> In my case it's just a rails server started with:
>      bundle exec rails server -p 5100
>
Possibly url-retrieve is being too picky about what it accepts. I'm 
afraid you'll have to debug it on your end, though. Sorry, I don't have 
much experience with this sort of debugging, but perhaps you can track 
all the bytes going from Emacs to your server and back again and see 
what the problem is.

Message #17 received at 23620 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23620 <at> debbugs.gnu.org
Subject: Re: 25.0.94; url-retrieve fails on localhost
Date: Wed, 01 Jun 2016 19:04:31 +0000

[Message part 1 (text/plain, inline)]

After some more digging, looks like this is a duplicate of #17976. Could
someone mark it as such?

[Message part 2 (text/html, inline)]

Message #24 received at 23620 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 17976 <at> debbugs.gnu.org
Cc: Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr>,
 Andreas Schwab <schwab <at> suse.de>, 23620 <at> debbugs.gnu.org,
 Artur Malabarba <bruce.connor.am <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: 24.3; url-retrieve-synchronously doesn't fallback to IPv4
Date: Sun, 26 Jun 2016 23:58:29 +0200

[Message part 1 (text/plain, inline)]

No further comment on the proposed patch, and as it should be a win for 
non-WINDOWSNT I decided to install it on the Emacs master branch. I 
looked into how libcurl addresses the issue, and it doesn't care whether 
the errno value reported by getsockopt is ECONNREFUSED so I adjusted the 
Emacs patch accordingly (see attached) before installing. Please give it 
a try if you have the time.

This patch does not affect behavior if WINDOWSNT. If the bug does not 
occur on MS-Windows I hope we can close Bug#17976. Otherwise we should 
leave the bug open for the WINDOWSNT case.

[0001-Try-other-addresses-when-connecting-to-multihomed.patch (text/x-patch, attachment)]

Message #27 received at 23620 <at> debbugs.gnu.org (full text, mbox):

From: Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Andreas Schwab <schwab <at> suse.de>, 23620 <at> debbugs.gnu.org,
 Artur Malabarba <bruce.connor.am <at> gmail.com>, 17976 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: 24.3; url-retrieve-synchronously doesn't fallback to IPv4
Date: Mon, 27 Jun 2016 01:20:52 +0200

Hi Paul,

I'm the original submitter of #17976.

I can confirm that I still see the bug with Emacs 25, and I don't see the
bug with current trunk (commit g2989ad9).

I'm not sure if it's possible, but I'd appreciate it if this patch could
be backported to Emacs 25 (which is what I run usually).

Thanks for your help,

-- Juliusz Chroboczek

Message #34 received at 23620 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Andreas Schwab <schwab <at> suse.de>,
 23620 <at> debbugs.gnu.org, Artur Malabarba <bruce.connor.am <at> gmail.com>,
 17976 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#17976: 24.3;
 url-retrieve-synchronously doesn't fallback to IPv4
Date: Sat, 21 Oct 2017 19:55:34 -0400

close 17976
quit

Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr> writes:

> I can confirm that I still see the bug with Emacs 25, and I don't see the
> bug with current trunk (commit g2989ad9).
>
> I'm not sure if it's possible, but I'd appreciate it if this patch could
> be backported to Emacs 25 (which is what I run usually).

I think it's clear enough by now that there's not going to be any more
Emacs 25 releases (unless there's another emergency, in which case this
patch still won't go in).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.