Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.3: A possible workaround for accessing localhost Network
If you're using a local proxy (Squid, Privoxy, Authoxy, ...) and you're having problems with download errors (outright failures, broken image icons, ...) under Panther, change your proxy settings to 127.0.0.1 instead of localhost.

There appears to be a problem with broken pipe errors somewhere in CoreFoundation, so any app that uses CoreFoundation to do its networking (Safari and NetNewswire, for example), will exhibit this problem. Camino is not affected by the problem.
    •    
  • Currently 2.17 / 5
  You rated: 5 / 5 (6 votes cast)
 
[10,806 views]  

10.3: A possible workaround for accessing localhost | 5 comments | Create New Account
Click here to return to the '10.3: A possible workaround for accessing localhost' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.3: A possible workaround for accessing localhost
Authored by: BillCole on Nov 19, '03 06:37:28PM

This problem seems to be due to missing support for IPv6, and not simply specific to CoreFoundation. If there is not an IPv6 listener in addition to the IPv4 listener but the connecting process does not understand the need to fall back to IPv4 (i.e. 127.0.0.1) after the IPv6 (i.e. ::1 ) connection fails, the result is that broken pipe.



[ Reply to This | # ]
10.3: A possible workaround for accessing localhost
Authored by: diamondsw on Nov 20, '03 01:59:41AM

This is lower level than CoreFoundation. SSHd will not resolve localhost properly when setting up SSH tunnels.



[ Reply to This | # ]
10.3: A possible workaround for accessing localhost
Authored by: olwylee on Nov 20, '03 09:05:28AM

I'm wondering if this also has to do with why I can set the mysqladmin password but not the mysqladmin localhost (hostname) password

And yes, root access is enabled on my machine.



[ Reply to This | # ]
10.3: A possible workaround for accessing localhost
Authored by: ptwithy on Nov 20, '03 12:36:56PM

Everyone should understand that localhost is a symbolic name, it is not hardwired into your OS, it is looked up using DNS just like any other symbolic name. Depending on your DNS settings (and your ISP if you have your DNS set to use your ISP's services) localhost may or may not resolve. It is up to the DNS server to have an entry (and reverse entry) for localhost. If that is missing, localhost just plain won't work as you expect.

127.0.0.1, on the other hand, is essentially hardwired. There is a special network interface for 127.0.0.1 that is the 'loopback' net that knows packets sent to 127.0.0.1 are for itself.



[ Reply to This | # ]
10.3: A possible workaround for accessing localhost
Authored by: BillCole on Nov 21, '03 05:33:55PM
It is up to the DNS server to have an entry (and reverse entry) for localhost. If that is missing, localhost just plain won't work as you expect.

Hopefully not. Every machine that needs TCP/IP name resolution of any sort SHOULD have its own local entry or entries for localhost in whatever local name resolution mechanism it uses. For example, MacOS X has a file at /etc/hosts that is used in single-user mode (and in fact during boot before networking or NetInfo is up) and the default NetInfo entries include localhost entries. Not having such entires locally is a very serious security hole because it would let a DNS server tell you who you are. I have seen people cause serious trouble by removing their local mapping of localhost or making it subsidiary to what DNS says.

What is happening with these failures is that at some point whatever process is asking for name resolution is getting back the IPv6 address for the loopback (::1) as the address of 'localhost' and trying to use it for a connection that cannot be made because there is no IPv6 listener for whatever it is trying to connect to. The program SHOULD then look for the other address for localhost (the IPv4 address 127.0.0.1) and connect to that instead, but some (many? most?) programs don't anticipate that particular failure mode and simply fail because the first connection failed.

If you want to see proper recovery in action, try 'telnet localhost 22' and note the success (if you have SSH on) then try 'telnet localhost 80' and note the initial failure and then success (if you have the web server running.)



[ Reply to This | # ]