GNU bug report logs - #17417
24.3.90; EWW on MS-Windows tries to connect imaginary FTP server when viewing "file://" URLs

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 17417 <at> debbugs.gnu.org
Subject: Re: bug#17417: 24.3.90;
 EWW on MS-Windows tries to connect imaginary FTP server when viewing
 "file://" URLs
Date: Thu, 13 Nov 2014 19:29:08 +0200

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: 17417 <at> debbugs.gnu.org
> Date: Thu, 13 Nov 2014 18:01:33 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Then visit the file in Emacs's eww like this:
> >
> >  emacs -Q
> >  M-x eww RET file:///D:/foo/bar/Unicode Standard.html RET
> >
> > The page is displayed, but Emacs also says
> >
> >   Opening FTP connection to d...
> >
> > Also, a buffer named *ftp anonymous <at> d* pops up showing this:
> >
> >   Invalid help command foo.
> >   open d
> >   Unknown host d.
> 
> That does sound rather, er, non-optimal.
> 
> > This does not happen when visiting the same page via http://.  I suspect
> > that the "D:" part of the URL fools eww or some function it calls to
> > perceive the URL as an FTP address, or something.
> 
> But unfortunately, I have no idea what might be causing this.
> eww is supposedly just passing the URL along to `url-retrieve'.
> 
> Does
> 
> (url-retrieve "file:///D:/foo/bar/Unicode Standard.html" 'ignore)
> 
> display the same failure mode?

No.  But then I can no longer reproduce the original problem, either.
So I guess this was fixed indirectly somehow.

Thanks.

Previous Next

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