InformAction Forums

 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (clean profile)
NoScript 1.9.9.18 (default options)
prefs: keyword.enabled = true/false

Steps to reproduce:
Visit http://to./ by clicking the link or enter the URL in location bar

Expected result:
Loads http://to./

Actual result:
Redirects to http://www.to.com/


No problems on Firefox 3.6b4 with the same NoScript version, only on 3.5.5
 

to, does not work.
http://www.to, does & goes (presumably) to the expected page.
http://www.to.com, also works, going to a different page.

Are you sure it is not your domain name completion settings in FF that is making the difference?

(Or is this specifically a 3.6 issue?)

 
It's http://to./ (yes, no TLD, or is using IDN ccTLD perhaps) not http://www.to/ 
It works in clean profile or safe mode



and other browsers
 

http://to./ takes me to the web page you describe in both a new Firefox profile without any extensions and one that has only NoScript installed using its default settings. I am not redirected to http://www.to.com. Does your problem persist if you Reset your NoScript settings? (You might want to save them first with the Export button. It resets the whitelist too.) This may seem unnecessary to you, since you say you're performing your test in a clean test profile with only NoScript installed, with its default settings. It's just that I'm unable to reproduce your problem. I'm afraid it "works for me". There appears to be something problematic in your system or setup somewhere.

I did notice that NoScript strips off the trailing ".", taking me to http://to/ instead, but it's still the same page. The trailing "." does not appear to be necessary. http://to/ works in a profile without NoScript too.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
NoScript 1.9.9.18

@Giorgio:
WTF kind of domain name is "to" anyway. (I'll see if I can find out on my own in the meantime.)
Edit: Answer: It's a short domain name.
Although "nslookup to" returns "*** vnsc-pri-dsl.genuity.net can't find to: Non-existent domain",
"nslookup to." returns

Non-authoritative answer:
Name: to
Address: 216.74.32.103

It looks like the Kingdom of Tonga wants to be known for exporting shortened URLs on the Internet. It's a pretty short start.

Alan Baxter wrote:Does your problem persist if you Reset your NoScript settings?

Yes

Alan Baxter wrote:I did notice that NoScript strips off the trailing ".", taking me to http://to/ instead, but it's still the same page. The trailing "." does not appear to be necessary. http://to/ works in a profile without NoScript too.

It also happened to me on Firefox 3.6b4 (with NS enabled), but on 3.5.5 (with NS disabled, or else it won't work) http://to/ (without the dot) redirects to to.com. But it's not NS problem, we can skip this.

Alan Baxter wrote:There appears to be something problematic in your system or setup somewhere.

I'm afraid so, but why does it only work if NS is disabled?

p.s.
I don't use proxies
 

I don't know what else to suggest. Could you run through the other suggestions in the Standard Diagnostic?
http://kb.mozillazine.org/Standard_diagnostic_-_Firefox

I am not having any problem with this and I have tried in on nearly 8 different configurations (including but not limited to different hardware, software, OS, versions, etc) so it suggests that it has something to do with YOUR specific configuration or installation. Have you tried the following:

1. Start using the ProfileManager ["C:\Program Files\Mozilla Firefox\firefox.exe" -profilemanager]

2. Create a new profile, name it whatever you want [NoScript Test]

3. Type the address and try without any extensions [http://to.]
? did it work?
?YES goto step 4
?NO then you have a problem that is beyond the application and probably has to do with your ISP gateway and how it is functioning, quasi proxy if you will and therefore not a NoScript issue, since it won't work without it either.

4. Don't configure anything, just install the latest NoScript version [latest development build]
? does it work?
?YES then no problems with NS, something has gotten messed up in your profile, repair it or start with a new one
?NO | But worked in step 3, then might be an extension conflict or something requiring further look
?NO | But didn't work in step 3 either, then again back to this not being an NS issue, your ISP gateway may be the problem, out of date DNS records, faulty DNS cache, who knows.

1.. 2.. 3..
Read my previous post veeeeeery carefully

http://forums.informaction.com/viewtopi ... 272#p13657

myself wrote:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (clean profile)

http://forums.informaction.com/viewtopi ... 272#p13660

myself wrote:It works in clean profile or safe mode

4... devel ...

http://noscript.net/getit#devel wrote:Latest development snapshot is identical to the official release above

i.e. 1.9.9.18

GµårÐïåñ wrote:...your ISP gateway may be the problem, out of date DNS records, faulty DNS cache, who knows.

If it's my ISP/DNS, it won't work even in new/clean profile or safe mode
http://forums.informaction.com/viewtopi ... 272#p13660

myself wrote:and other browsers

 

This looks like a difference in Gecko's full qualified domain name handling between 1.9.1 and 1.9.2.
Just turn the noscript.canonicalFQDN preference to false.

LouCypher wrote:1.. 2.. 3..
Read my previous post veeeeeery carefully

I did and it is obviously working for everyone else but you. That suggests you didn't do something or do it the right way, regardless of how "VERY" carefully you stated it earlier. We are here to help you, if you don't want it, then by all means ignore and argue with us all, or you can do what you are told and see if it works like it does for everyone else. Now I am going to stop helping you and leave it to others who may be willing to spin their wheels with an uncooperative support request.

Giorgio Maone wrote:This looks like a difference in Gecko's full qualified domain name handling between 1.9.1 and 1.9.2.

Yes, because it works on Firefox 3.6 beta

Giorgio Maone wrote:Just turn the noscript.canonicalFQDN preference to false.

Set the noscript.canonicalFQDN to false works. Thanks, Giorgio.
This thread has been marked as resolved.
 

On Windows, at least, if you have a dns suffix configured or dhcp assigned (example.com), and an app attempts to resolve a single label unqualified domain name (to), the dns client will append the suffix to it and try to resolve to.example.com, which will likely fail, causing Fx to either dns error or try to.com and other variations. To avoid this you have to qualify the domain with a trailing dot (to.)

When you navigate to http://to./ and canonicalFQDN is true, NS will strip the trailing dot. @Giorgio, what is the reason for the canonicalization of the host name? Why is it on by default?

After the dot is stripped, lookup of "to" will fail if the DNS Client service (dnscache) is off, resulting in behavior, the OP described. If dnscache is running, the lookup of "to" will succeed, because "to." has already been looked up and cached in the canonicalization step.

al_9x wrote: what is the reason for the canonicalization of the host name? Why is it on by default?

It has been introduced long time ago in order to prevent XSS false positives due to the FQDN and the "normal" name being intermixed in the same page.
However, since then, XSS filtering has become much more specific, therefore it may make sense to turn it off by default in next release.