bug#12893: 24.2.50; url-retrieve fails for localhost

bug#12893: 24.2.50; url-retrieve fails for localhost

[Dmitry Gutov]

I have an HTTP server running, started from an inferior process.

If I evaluate (switch-to-buffer (url-retrieve-synchronously
"http://localhost:24959/classes")), it brings me to an empty buffer
which has "failed" in the mode line.

If I call the asynchronous version, it passes this into the callback:

((:error (error connection-failed failed with code 111
 :host localhost :service 24959)))

Strangely, it works if I replace "localhost" with "127.0.0.1" or even
"localhost.localdomain". But neither Firefox nor curl have a problem
with reading from the first version of the URL.

In GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0)
 of 2012-11-15 on vbx
Bzr revision: 110872 rgm@gnu.org-20121115061756-ncyfcon4pkq7ku57
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Ubuntu 12.10

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  recentf-mode: t
  shell-dirtrack-mode: t
  helm-match-plugin-mode: t
  elisp-slime-nav-mode: t
  paredit-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-diff-hl-mode: t
  diff-hl-mode: t
  diff-auto-refine-mode: t
  savehist-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  global-auto-revert-mode: t
  autopair-global-mode: t
  cua-mode: t
  winner-mode: t
  ido-ubiquitous-mode: t
  ido-everywhere: t
  show-paren-mode: t
  global-ethan-wspace-mode: t
  ethan-wspace-mode: t
  ethan-wspace-clean-many-nls-eof-mode: t
  ethan-wspace-clean-no-nl-eof-mode: t
  ethan-wspace-clean-eol-mode: t
  ethan-wspace-clean-tabs-mode: t
  eproject-mode: t
  eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

Recent input:
<M-return> <M-return> <down-mouse-1> <mouse-1> <down-mouse-1> 
<mouse-1> <M-return> C-x C-g C-x C-g C-; g e m f <return> 
M-: <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <down> <return> 
<up> <end> <home> q M-x r v m <return> M-: <up> <up> 
<down> <return> <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-1> M-x z o s s i m a <return> M-x z o s s i 
m a - j u m p <return> <down> M-x <return> C-g M-x 
f i n d - l i b <return> z o s s i m a <return> <up> 
<left> <left> <left> <left> <left> <C-backspace> <C-backspace> 
<C-backspace> <C-backspace> <C-backspace> <C-backspace> 
<C-backspace> l o c a l h o s t C-M-x C-x C-s <C-tab> 
M-. <up> <up> M-. <C-tab> <help-echo> <help-echo> M-x 
r e <return>

Recent messages:
zossima.el [Gemfile] -scratch-
Contacting host: localhost:24959
save-current-buffer: Search failed: "

"
Contacting host: localhost:24959
save-current-buffer: Search failed: "

"
Gemfile [zossima.el] -scratch-

Load-path shadows:
/home/gutov/.emacs.d/site-lisp/smartrep.el/smartrep hides ~/.emacs.d/site-lisp/smartrep
/home/gutov/.emacs.d/elpa/magit-20121014.1043/.dir-locals hides /home/gutov/emacs-bzr/emacs-24/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader sendmail mule-util
find-func mail-utils network-stream starttls url-cache url-http tls
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw url-auth zossima
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap json rvm debug unsafep flymake-ruby
flymake-easy flymake ruby-electric ruby-tools subword inf-ruby ruby-mode
helm-misc tramp-cache tramp-sh recentf tree-widget wid-edit bow
helm-files image-dired tramp tramp-compat tramp-loaddefs shell pcomplete
format-spec dired-x dired-aux thingatpt helm-tags helm-locate helm-help
helm-external helm-bookmark helm-buffers helm-grep helm-regexp grep
helm-elscreen helm-utils compile helm-match-plugin helm helm-config
elisp-slime-nav etags paredit saveplace win-switch undo-tree diff
diff-hl smartrep face-remap vc-hg vc-git vc-dir ewoc vc vc-dispatcher
diff-mode savehist yasnippet autorevert autopair cua-base winner
point-stack .emacs-loaddefs server auto-complete-autoloads
autopair-autoloads clojure-mode-autoloads coffee-mode-autoloads
expand-region-autoloads flymake-coffee-autoloads flymake-ruby-autoloads
flymake-easy-autoloads helm-descbinds-autoloads iedit-autoloads
iy-go-to-char-autoloads markdown-mode-autoloads move-text-autoloads
popup-autoloads rainbow-mode-autoloads ruby-electric-autoloads
ruby-tools-autoloads rvm-autoloads sass-mode-autoloads lisp-mnt
finder-inf starter-kit-bindings-autoloads windmove
starter-kit-lisp-autoloads elisp-slime-nav-autoloads
starter-kit-autoloads smex starter-kit-misc warnings ffap url-parse
auth-source eieio byte-opt bytecomp byte-compile cconv gnus-util mm-util
mail-prsvr password-cache url-vars ido-ubiquitous ido paren
starter-kit-defuns uniquify magit-autoloads ido-ubiquitous-autoloads
smex-autoloads find-file-in-project-autoloads
idle-highlight-mode-autoloads paredit-autoloads switch-window-autoloads
typing-autoloads undo-tree-autoloads wgrep-autoloads
win-switch-autoloads yaml-mode-autoloads yasnippet-autoloads
zossima-autoloads inf-ruby-autoloads package devenv eproject-extras
ibuf-macs ibuf-ext ibuffer iswitchb ethan-wspace eproject derived
easy-mmode esh-var esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg eldoc
esh-groups eshell esh-module esh-mode esh-util progmodes mmm mmm-auto
mmm-vars mmm-compat cl-macs gv cl keys quail help-mode easymenu hippie
hippie-exp comint ansi-color dired winring ring transpose-frame iflipb
misc prefs help-at-pt cus-start cus-load edmacro kmacro defuns advice
help-fns cl-lib advice-preload time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

bug#12893: 24.2.50; url-retrieve fails for localhost

[Chong Yidong]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I have an HTTP server running, started from an inferior process.
>
> If I evaluate (switch-to-buffer (url-retrieve-synchronously
> "http://localhost:24959/classes")), it brings me to an empty buffer
> which has "failed" in the mode line.
>
> If I call the asynchronous version, it passes this into the callback:
>
> ((:error (error connection-failed failed with code 111
>  :host localhost :service 24959)))

I think this may be the same as Bug#12374, which was just fixed by
Takafumi Arakaki.  Could you try again with latest trunk and see if the
problem is still there?

bug#12893: 24.2.50; url-retrieve fails for localhost

[Dmitry Gutov]

On 22.12.2012 7:03, Chong Yidong wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> I have an HTTP server running, started from an inferior process.
>>
>> If I evaluate (switch-to-buffer (url-retrieve-synchronously
>> "http://localhost:24959/classes")), it brings me to an empty buffer
>> which has "failed" in the mode line.
>>
>> If I call the asynchronous version, it passes this into the callback:
>>
>> ((:error (error connection-failed failed with code 111
>>   :host localhost :service 24959)))
>
> I think this may be the same as Bug#12374, which was just fixed by
> Takafumi Arakaki.  Could you try again with latest trunk and see if the
> problem is still there?

Tried it, still there.

This might be a quirk of configuration (the OS is installed on a virtual 
machine), but the obvious other software works properly.

bug#12893: 24.2.50; url-retrieve fails for localhost

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 22.12.2012 7:03, Chong Yidong wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> I have an HTTP server running, started from an inferior process.
>>>
>>> If I evaluate (switch-to-buffer (url-retrieve-synchronously
>>> "http://localhost:24959/classes")), it brings me to an empty buffer
>>> which has "failed" in the mode line.
>>>
>>> If I call the asynchronous version, it passes this into the callback:
>>>
>>> ((:error (error connection-failed failed with code 111
>>>   :host localhost :service 24959)))
>>
>> I think this may be the same as Bug#12374, which was just fixed by
>> Takafumi Arakaki.  Could you try again with latest trunk and see if the
>> problem is still there?
>
> Tried it, still there.

Why did localhost:24959 refuse connection?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12893: 24.2.50; url-retrieve fails for localhost

[Dmitry Gutov]

On 22.12.2012 13:44, Andreas Schwab wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 22.12.2012 7:03, Chong Yidong wrote:
>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>
>>>> I have an HTTP server running, started from an inferior process.
>>>>
>>>> If I evaluate (switch-to-buffer (url-retrieve-synchronously
>>>> "http://localhost:24959/classes")), it brings me to an empty buffer
>>>> which has "failed" in the mode line.
>>>>
>>>> If I call the asynchronous version, it passes this into the callback:
>>>>
>>>> ((:error (error connection-failed failed with code 111
>>>>    :host localhost :service 24959)))
>>>
>>> I think this may be the same as Bug#12374, which was just fixed by
>>> Takafumi Arakaki.  Could you try again with latest trunk and see if the
>>> problem is still there?
>>
>> Tried it, still there.
>
> Why did localhost:24959 refuse connection?

How can I find out the answer?

bug#12893: 24.2.50; url-retrieve fails for localhost

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 22.12.2012 13:44, Andreas Schwab wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> On 22.12.2012 7:03, Chong Yidong wrote:
>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>>
>>>>> I have an HTTP server running, started from an inferior process.
>>>>>
>>>>> If I evaluate (switch-to-buffer (url-retrieve-synchronously
>>>>> "http://localhost:24959/classes")), it brings me to an empty buffer
>>>>> which has "failed" in the mode line.
>>>>>
>>>>> If I call the asynchronous version, it passes this into the callback:
>>>>>
>>>>> ((:error (error connection-failed failed with code 111
>>>>>    :host localhost :service 24959)))
>>>>
>>>> I think this may be the same as Bug#12374, which was just fixed by
>>>> Takafumi Arakaki.  Could you try again with latest trunk and see if the
>>>> problem is still there?
>>>
>>> Tried it, still there.
>>
>> Why did localhost:24959 refuse connection?
>
> How can I find out the answer?

Look at the server log?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12893: 24.2.50; url-retrieve fails for localhost

[Dmitry Gutov]

On 22.12.2012 14:07, Andreas Schwab wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 22.12.2012 13:44, Andreas Schwab wrote:
>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>
>>>> On 22.12.2012 7:03, Chong Yidong wrote:
>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>>>
>>>>>> I have an HTTP server running, started from an inferior process.
>>>>>>
>>>>>> If I evaluate (switch-to-buffer (url-retrieve-synchronously
>>>>>> "http://localhost:24959/classes")), it brings me to an empty buffer
>>>>>> which has "failed" in the mode line.
>>>>>>
>>>>>> If I call the asynchronous version, it passes this into the callback:
>>>>>>
>>>>>> ((:error (error connection-failed failed with code 111
>>>>>>     :host localhost :service 24959)))
>>>>>
>>>>> I think this may be the same as Bug#12374, which was just fixed by
>>>>> Takafumi Arakaki.  Could you try again with latest trunk and see if the
>>>>> problem is still there?
>>>>
>>>> Tried it, still there.
>>>
>>> Why did localhost:24959 refuse connection?
>>
>> How can I find out the answer?
>
> Look at the server log?

The access log is empty. And there's nothing printed to stderr. When 
connecting from Emacs to "localhost", that is.

I'll try to concoct a minimal example a bit later.

bug#12893: 24.2.50; url-retrieve fails for localhost

[Andreas Schwab]

Do you have a proxy configured?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12893: 24.2.50; url-retrieve fails for localhost

[Dmitry Gutov]

On 22.12.2012 16:15, Andreas Schwab wrote:
> Do you have a proxy configured?

gutov@vbx:~$ env | grep -i proxy
UBUNTU_MENUPROXY=libappmenu.so
gutov@vbx:~$ cat ~/.curlrc
cat: /home/gutov/.curlrc: No such file or directory

bug#12893: 24.2.50; url-retrieve fails for localhost

[Andreas Schwab]

You need to look at the url-proxy-services variable.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12893: 24.2.50; url-retrieve fails for localhost

[Dmitry Gutov]

On 22.12.2012 17:52, Andreas Schwab wrote:
> You need to look at the url-proxy-services variable.
>

It has the default value of nil.

So, here's the small example of a web server in Ruby:

```
require 'webrick'

class Server < WEBrick::HTTPServer
   def initialize(port)
     super(Port: port)
     mount("/", Handler)
   end

   class Handler < WEBrick::HTTPServlet::AbstractServlet
     def do_GET(req, res)
       res["Content-Type"] = "text/html"
       res.status = 200
       res.body = "Hello!\n"
       raise WEBrick::HTTPStatus::OK
     end
   end
end

server = Server.new(54321)

%w(INT TERM).each { |s| trap(s) { server.stop } }

server.start
```

When I run it (ruby server.rb), I see the following output:

[2012-12-23 04:12:53] INFO  WEBrick 1.3.1
[2012-12-23 04:12:53] INFO  ruby 1.9.3 (2012-11-10) [x86_64-linux]
[2012-12-23 04:12:53] WARN  TCPServer Error: Address already in use - 
bind(2)
[2012-12-23 04:12:53] INFO  Server#start: pid=4838 port=54321

The third line probably hints at problem with the system, but

curl http://localhost:54321/

outputs the expected "Hello!", and running

lsof -i TCP:54321

doesn't show anything when the server isn't running.

Now, when the server is running, evaluating

(switch-to-buffer (url-retrieve-synchronously "http://localhost:54321/"))

shows an empty buffer, whereas

(switch-to-buffer (url-retrieve-synchronously "http://127.0.0.1:54321/"))

shows the expected contents.

Now, I couldn't reproduce the problem on my Windows machine, so the test 
case is probably not very useful.

If you tell me where to poke to solve the "address already in use" 
warning, I'll be sure to do that.

bug#12893: 24.2.50; url-retrieve fails for localhost

[Juliusz Chroboczek]

> If I evaluate (switch-to-buffer (url-retrieve-synchronously
> "http://localhost:24959/classes")), it brings me to an empty buffer
> which has "failed" in the mode line.
[...]
> Strangely, it works if I replace "localhost" with "127.0.0.1" or even
> "localhost.localdomain". But neither Firefox nor curl have a problem
> with reading from the first version of the URL.

This might be a duplicate of #17976.  If localhost points at both ::1 and
127.0.0.1, then attempting to connect localhost will first try the IPv6,
and if the server is only listening on IPv4, it will trigger #17976.

-- Juliusz

bug#12893: 24.2.50; url-retrieve fails for localhost

[Dmitry Gutov]

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

> This might be a duplicate of #17976.  If localhost points at both ::1 and
> 127.0.0.1, then attempting to connect localhost will first try the IPv6,
> and if the server is only listening on IPv4, it will trigger #17976.

Thanks, that's probably it.  I can't confirm that, though, since the
system I saw this on is long gone.  Better close this.