User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:184.108.40.206) Gecko/20080915 Camino/1.6.4 (like Firefox/220.127.116.11) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:18.104.22.168) Gecko/20080915 Camino/1.6.4 (like Firefox/22.214.171.124) When a word like gmail or wikipedia is entered in Safari location bar, Safari automatically tries to load the following addresses www.gmail.com or www.wikipedia.com even if it is not in the history or bookmarks. Reproducible: Always Steps to Reproduce: Given a site whose location is www.test.com 1.enter test in the location bar 2.click Go Actual Results: if there is no http://test returns a 404 Expected Results: should load the page http://www.test.com cf Safari behaviour on that
This isn't a dupe; Camino does automatically try www.foo.com if foo doesn't resolve. You say you receive a 404--the page actually says 404 (as opposed to having a Camino icon, and text starting "Address Not Found"? That would suggest that your DNS server is resolving "test" to a valid address, which would prevent Camino's www./.com auto-correction.
...or that a proxy server is saying that "http://test" is valid. Privoxy, in particular, is known to do this, though it's fairly obvious when it happens that Privoxy has caused it. cl
You are right I have not been accurate. 404 is not the error I get. If I enter 'wikipedia' in the location bar, Camino try http://wikipedia and I get this : Bad Gateway The following error occurred: [code=DNS_HOST_NOT_FOUND] The host name was not found during the DNS lookup. Contact your system administrator if the problem is not found by retrying the URL. Please contact the administrator. I don't think that come from the proxy, I get the same result at home and at work and my enterprise has his own proxy server. Moreover Safari resolve 'wikipedia' correctly. Mathieu
It sounds like browser.fixup.alternate.enabled isn't set to true. Check in about:config and ensure that it is.
Sorry I don't know what you're talking about. There is no such file in Application Support neither in Preferences directory. The org.mozilla.camino plist has no key named browser/fixup.alternate.enabled . Can you be a little more specific please ? Mathieu
Type 'about:config' in the url bar In the sarch bar at the top of the page: paste: browser.fixup.alternate.enabled It should false or true.
It is set to true. false does not change anything. Mathieu
(In reply to comment #4) > Bad Gateway > The following error occurred: > > [code=DNS_HOST_NOT_FOUND] The host name was not found during the DNS lookup. > Contact your system administrator if the problem is not found by retrying the > URL. > Please contact the administrator. This is not an error message generated by Camino; it's coming from a DNS or proxy server. It does seem, though, like Camino tried to resolve this to a local host (that is, it prepended http: instead of simply erroring); it sounds a bit like the data flow in bug 324424 comment 3 (though this is probably not a dupe of that bug).
Do you use a proxy at home?
No proxy at home, but the page I get is different ; it is a search result page generated by openDNS. But what I get is not important, What is important is that I get something different from Safari. but maybe is it more a feature request than a bug report that I should have filled; I think Safari test if the page loaded comes from the requested location, and if not, tries to add www and .com
I have no idea how Safari manages not to trigger it, but what you're seeing at home is definitely the result of OpenDNS (stupidly) returning a "found" response for domains that are not, in fact, valid (and therefore can't possibly be found). It sounds like what you're seeing at work is the result of the proxy server doing basically the same thing, and I'm sure you'll find Firefox has the same problem. This is probably a CANTFIX unless someone can explain how exactly Safari manages not to trigger this sort of thing and still makes fixup work, and then it would be a Gecko bug, not a Camino one.
(In reply to comment #11) > I think Safari test if the page loaded comes from the requested location, The point of the DNS system is that it gives the location (IP address) corresponding to the domain name. If your DNS lies, as is the case with OpenDNS, a browser has no way of knowing. There's nothing to test against; if we know the IP address already, we wouldn't need the DNS.
My ISP at home does the same nasty lying as OpenDNS, and Safari fails at autocompletion just as Camino does; I'm not sure how Safari is working for you at home.
@Chris Lawson When my MacBook is a little overloaded I can see Safari beginning to load the openDNS page and immadiately after loading the page I requested. I don't know how they do it, but I don't think it is at the engine level to manage that but at the URL loading system which I think is made in Cocoa ; maybe a comparison of the URL loaded and the URL requested (but only if the user has entered a single word in the address bar), but it is going to be a little messy ... maybe it is for this kind of thing Safari ends up with a footprint of 400 MB in RAM (the reason I switched from Safari to Camino). but I don't know enough how Camino works so if you think you can't fix it, you can close it. @Stuart Morgan I was not talking about name resolution, but if you display www.opendns.com/search?... (or something like that) in the address bar, you know that is different from wikipedia.xxx.xxx or xxx.wikipedia.xxx, but as said before it is only in the case the user has entered a single word in the address bar (to not prevent redirection), but it surely is not the right way to do it. @Smokey Ardisson But I AM sur how it works, do you want to come at my home to test it ? :) Anyway, it seems there is a consensus to say it can't be resolved, it was annoying at the beginning when my history was empty but now that I have suggestions I can live with it (it is a key stroke or 2 further than in Safari). Maybe a workaround could be to include bookmarks in the suggestions list.
Closing INVALID, since this is due to OpenDNS. Doing string matching of what was typed vs what page it eventually settles on would break all kinds of legitimate redirection, and we aren't going to special-case OpenDNS.