76945 - Proxy: hostnames are not sent as fqdns

Status: VERIFIED INVALID

(Core :: Networking, defect)

Description

[ajax]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2 i686; en-US; 0.8.1) Gecko/20010416
BuildID:    0.8.1

in previous versions of netscape, host names relative to the domain name would
resolve properly; eg, http://www/ would give the same results as
http://www.mozilla.org/.  this is not true for mozilla.

Reproducible: Always
Steps to Reproduce:
1. determine your machine's domain name (example.org)
2. find a machine in example.org that runs a web server (web.example.org)
3. type http://web/ into the url bar.  watch the web page fail to load.

Actual Results:  the expected web page did not load.

Expected Results:  that the web page would load.

my setup uses a proxy configuration; this error is evidenced in my setup as a
DNS error message from the server (implying that the proxy server isn't doing
relative DNS properly either).  however, this was (and is) not the behavior if i
use netscape 4.x, which implies that older browsers did it differently.  either
mozilla should recognize the error (an HTTP 503, X-Squid-Error: ERR_DNS_FAIL) or
should expand (or resolve) relative domain names before passing them on to the
proxy.

actually, the proxy should be set up intelligently enough to do proper relative
DNS, but the proxy configuration is not always in the hands of the user.

Comment 1

[Boris Zbarsky [:bzbarsky]]

er... confirming.  But yes, DNS should be handled by the OS/proxy.  It's a
little surprising that NS 4.x worked if those are misconfigured.

Comment 2

[ajax]

btw, this has happened with all mozilla builds i've used in this configuration
(m18, 0.7, and 0.8.1.).

the only thing i can think of that would cause this behavior is that mozilla
passes domain names to the proxy raw, rather than doing a dns lookup.  (this is
in fact what mozilla does, as verified by ethereal.  i have not checked the
behavior with 4.x.)  this could be considered a feature.

Comment 3

[benc]

qa to me, -qawanted keyword.

re: re hostname->fqdn expansion. as time wears on, this has proven to be a 
readly bad feature. When we moved a lot of stuff from mcom.com and netscape.com 
to iplanet.com, chaos ensued. I'm going to indulge myself for a moment and tell 
you this is really bad.

That being said, yes, ajax's comments are likely correct, Comm 4 probably 
remembered to try multiple DNS lookoups based on a single "hostname" in the URL 
field. 

I'll put this on my list of things to do.

Comment 4

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 5

[ajax]

marking invalid.  if (as in my initial description) you set example.org to be
one of the domains not to use the proxy server for (presumably because it's
local) then relative hostnames work.  this is almost certainly how i had ns4 set
up (it's been a while).  if relative hostnames are expected to work for a given
network, then the proxy admin should change the autoconfig scripts appropriately.

there may still be a robustness argument to be made about mozilla
expanding/resolving relative hostnames, but it's by no means critical.

Comment 6

[benc]

VERIFIED: (mozilla 1.0 cleanup)

I can't tell what the exact combination of elements cause the behavior here, but
it always turns out to be a mixture of Mozilla's not so-robust no-proxy
implementation, the lack of coherent default domain support, and a hard to see
proxy redirect response to a hostname.