User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 I have a PHP script I'm developing. It's at http://localhost/scriptDir/script.php But my script times out. If I put localhost/scriptDir/script.php into the browser's address bar to access my script, after the timeout, the url in the address bar shows: http://www.localhost.com/scriptDir/script.php Reproducible: Always Steps to Reproduce: Expected Results: There is no way that a resolved address should get repointed to a different unresolved address. Even if I stretch my imagination to thinking that this type of redirection upon localhost is useful for that less than .01% of people who meant to type localhost.com instead of localhost, is there ANY utility servered by retaining that unresolved address in the address bar (and the Try again button, and the F5 refresh). What I'm saying is that if we are going to try to double guess the user, then let's at least have the decency to admit when we're wrong and assume that their bad guess is better than our bad guess. However, we shouldn't be double guessing on localhost anyway. Csaba Gabor from Vienna This bug has appeared multiple times, but after trawling through bug lists, I only saw it appearing in relationship to port issues. Sorry if I've missed a current duplicate.

What do you mean by "my script times out?" Do you mean: The web server is so slow, it never establishes a connection? Or the script is so slow, the response is never sent down the connection?

The latter: The script is too slow. Specifically, I found this problem when the script I was working on kept hanging.

This basically looks like a dup of bug 150025 to me (exclude "localhost" from domain guessing). But bug 150025 comment 7 claims that "we no longer do domain guessing for errors other than host not found", which is clearly not the case here. So either that comment is wrong or something else is going on here...

Christian was looking at the main point that Internet Keywords fires. Domain guessing traps errors later, and traps two cases: http://lxr.mozilla.org/mozilla1.8/source/docshell/base/nsWebShell.cpp#761 757 // 758 // Now try change the address, e.g. turn http://foo into http://www.foo.com 759 // 760 if (aStatus == NS_ERROR_UNKNOWN_HOST || 761 aStatus == NS_ERROR_NET_RESET) http://lxr.mozilla.org/mozilla1.8/source/netwerk/base/public/nsNetError.h#252 187 * The connection was established, but no data was ever received. 188 */ 189 #define NS_ERROR_NET_RESET \ 190 NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_NETWORK, 20) So, the problem here is that the actual error conditions is pretty esoteric. When I actually worked on testing Necko for mozilla this was an error condition that was on my list of things to test for, but never got around to testing. (Believe it or not, most networking code is lucky to do 3 of 4 most common errors correctly...) So the solution here to remove the NS_ERROR_NET, with some careful review of how this changes the structure of the error handling. This error was actually trapped for IK and DG originally. Because IK always happens first (and is on by default in most products), nobody ever noticed this. Recently, the trap for IK was removed: 1.628 cbiesinger%web.de 2004-01-28 13:32 184433 Internet Keywords triggered by "connection refused" errors. fix it to only trigger if the hostname is unknown. patch by Jerry Talkington <jtalkington@users.sourceforge.net> r=adamlock sr=darin ...so now this is visible.

I have the same problem with firefox 3 beta 4. It's not that the script times out, but that I am debugging the web server and killing the process in the middle. Then when I switch back to firefox, the url at the address bar is http://www.localhost.com/myscript. This is very annoying. Web development should be fun :)

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.