161699 - Domain Guessing: should not attempt for FQDNs

Status: NEW

(Core :: DOM: Navigation, defect, P5)

Description

[timeless]

preface:
* back-step.timeless is in some of my computer's host files and my computer is
supposed to check timeless before rummaging through dns.
* This computer didn't have an entry for back-step alone.

steps to reproduce:
make sure your dns does not have an entry for back-step and load http://back-step./

actual results:
www.back-step. could not be found. Please check the name and try again.

expected results:
back-step could not be found. Please check the name and try again.

I think the bug is in uriloader/urlbar/... but i'm starting this in networking
to make sure my expected results are reasonable (esp my expectation that the
error not include a dot at the end of the hostname).

Comment 1

[Ian Neal]

I presume this is without any sort of proxy server in the equation?

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is URI fixup.

Comment 3

[Adam Lock]

Duping against bug 115539. There is a pref to disable fixup (see the patch) but
no UI for it yet.

*** This bug has been marked as a duplicate of 115539 ***

Comment 4

[timeless]

but i don't want to disable fixup for all cases, i just want certain things not
to be 'fixed'.

Comment 5

[benc]

Actually, I don't think is a dupe. I think Timeless is saying that if the
hostname in the URL has a trailing ".", it should be treated as an FQDN, and
Domain Guessing should not touch it.

I did a dupe check, and could not find such a bug.

In general, we don't give FQDNs the proper treatment, see bug 124565. DNS
caching usually hides the performance problems.

Comment 6

[Adam Lock]

Perhaps this should be reassigned to netwerk

I've traced it through and the URI fixup doesn't touch this URL the first time
around and happily returns an nsIURI object for it. Therefore the issue must lie
in the networking layer when it attempts to open the URL. The fixup only appends
the www. on the front after the first channel returned with an error.

Now it would be an error for fixup to make an alternate if there is none, so
perhaps there is scope for a patch to prevent the alternate fixup from occuring
at all, or to at least fix it up properly with the .com as well.

I have little idea what an FDQN is, and I doubt that the majority of people who
accidentally stick a dot on the end would either. So probably the latter option
of fixing the .com code would be the best thing to do - the assumption being
that also fixing the networking code would usually prevent the alternate fixup
being required if it connected as intended.

Comment 7

[Adam Lock]

-> Network

Comment 8

[Darin Fisher]

adam: networking would not do any fixup here.  if you ask for "foo." then necko
will try to load "foo." and gethostbyname would not try to do any domain
guessing when confronted with a hostname ending in a dot.  (hostname ending with
a dot means a hostname that is fully qualified... a fully qualified domain name
or FQDN.)  in other words, i think this bug is about not prepending www. to
"foo." or am i mistaken?  since urlfixup is the code responsible for prepending
www. to the hostname, i think that code is at fault here.  it should check for
trailing dot and honor the hostname as a FQDN.

-> docshell

Comment 9

[Adam Lock]

What is a FQDN exactly? I still have no idea.

My analysis of this problem was that fixup was only occuring after the original
URL failed to load. So there is scope to make fixup not botch the fixup *after*
loading the first time fails but I'm not sure I should just ignore it. It seems
more likely that newbies are going to put a dot on the end by accident than
other uses so I would be inclined to fixup foo. as www.foo.com if loading foo.
failed.

Comment 10

[Darin Fisher]

so, FQDN is a hostname that ends in a dot.  that's all.  it means that DNS
system shouldn't try appending domains.

example:  www.cnn.com. is the FQDN of www.cnn.com

as for whether to fixup this URL or not, i'm not entirely sure either.  you make
a good point about the most likely scenario.

Comment 11

[timeless]

Ok, it turns out getting a decent definition for FQDN on google isn't simple
http://google.com/search?q=cache:5ZpxSZ6BCtUC:www.iso.port.ac.uk/~mike/docs/internet/internet/node23.html+&hl=en&ie=UTF-8
This url should work for a while.

<blockquote src="http://www.iso.port.ac.uk/~mike/docs/internet/internet/node23.html">
Each machine on the Internet has its own Fully Qualified Domain Name<A NAME="273">&#160;</A>
(FQDN<A NAME="274">&#160;</A> for short) which looks like <I>ranger.hum.port.ac.uk.</I>
(the last ``.'' is quite important). The name tells you a few things about
the machine as it is very carefully structured. The least important part is
at the left side -- <I>ranger</I> which is simply the name of the machine,
which usually has little or no meaning, and is called the <I>host name</I><A NAME="278">&#160;</A>.
</blockquote>

<blockquote src="http://www.iso.port.ac.uk/~mike/docs/internet/internet/node23.html">
The remaining part of the FQDN is the <I>domain name</I><A NAME="288">&#160;</A>,
and is subdivided by the ``.'''s, and is arranged with the top level at the
right, and the bottom level at the left. For instance, using the example used
at the start of the previous paragraph, ``<I>.</I>'' at the extreme right
is the root domain into which all other domains fit. The <I>uk</I> to the
left of this indicates that the machine is in Great Britain, and the <I>ac</I>
indicates that the machine is in an academic institution. The <I>port</I>   
</blockquote>

basically. If I write 'back-step.' i'm writing an FQDN and i'm writing it
because i *want* to Fully Qualify the DN.

Imagine someone sending mail to:
Adam Lock
cubicle 10 (yours)
501 East Middlefield Road, MV-059
Mountain View, CA 94043-4042

and imagine that the post man can't find your cubicle, so he decides to do a
search for adam lock and finds 
Adam Lock
10 Cemitary Row
Redfield, NY 13437

And then delivers the mail to that address instead.

It's ok to do searches if the user says it's ok when the user doesn't fully
qualify an address, e.g. 'snail-mailto:Adam Lock'

in an office or on a private lan, one might have an internal server similar to
something on the internet, but one might not want anyone on the internet to
know that the internal server or something like it exists.

If the address I wrote is wrong, then I should be told that it's wrong,
and I definitely should not be told that a corrected address is wrong.

An amusing example of providing an error about corrected data: urls.
Load 'data:text,text' in mozilla. You'll get an error saying mozilla can't
handle content of type 'text/plain'. What you should get if it's really an
error is something that says mozilla can't handle content of type 'text'.

Back to my snail mail example. If you wrote that letter, and the post man
was unable to deliver to the Adam Lock at Cemitary Row (there's a good reason)
would you want the post man to return the letter and say "I couldn't deliver it
to the Adam Lock at Cemitary Row" or to say that "I couldn't deliver it to the
Adam Lock at East Middlefield Road"?

Personally when I enter a FQDN I expect to get a response based on it (for
privacy and security reasons). And when I get an error, I expect the error to
be based on what I enter. IMO the easiest and best fix is to just stop when the
FQDN lookup errors. But I will settle (although there are others who might
complain) for just getting an error about the FQDN [after fixup fails].

Comment 12

[benc]

Timeless is basically saying:

domain guessing should not fire if the URL input was any DNS legal string that
ended in "."

As for the bogus error message, that is bug 66183.

Comment 13

[Markus Lindström]

To keep in the line with the "don't touch my FQDN" objective, Gecko also shouldn't  touch the "www." URL, which is currently changed to "www..com".