14431 - Problems with virtual hosts in mozilla

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Ludovic Hirlimann]

Mozilla build ID is : 1999091306.
taken from nightly/latest a few minutes ago. date of the tar.gz archive is 20
Sept. Running debian "potato".

If I want to connect to the above url site. I end-up on www.zacrom.net/ which is
the name of the provider that hosts the www.frbug.org domain. This domain works
fine with Netscape 4.6.1 on the same machine.

Comment 1

[Ludovic Hirlimann]

Attachment: output of mozilla whila going to the site

Comment 2

[Ludovic Hirlimann]

The server is run on a MacIntosch - Software used is unknow to me

Comment 3

[Ludovic Hirlimann]

The bug is reproductible with the win32 version of mozilla. from Nightly builds
date of the mozilla-win32.zip is Sept27 13:59 .....

Comment 4

[Andreas Otte]

It also happens on linux 10-02-99

Comment 5

[Andreas Otte]

I think this is an HTTP 1.1 issue, see Name-based Virtual Hosts Support. It
should go away when we switch to 1.1.

See some stuff from the RFC:



5.2 The Resource Identified by a Request

   The exact resource identified by an Internet request is determined by
   examining both the Request-URI and the Host header field.

   An origin server that does not allow resources to differ by the
   requested host MAY ignore the Host header field value when
   determining the resource identified by an HTTP/1.1 request. (But see
   section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)

   An origin server that does differentiate resources based on the host
   requested (sometimes referred to as virtual hosts or vanity host
   names) MUST use the following rules for determining the requested
   resource on an HTTP/1.1 request:

   1. If Request-URI is an absoluteURI, the host is part of the
     Request-URI. Any Host header field value in the request MUST be
     ignored.

   2. If the Request-URI is not an absoluteURI, and the request includes
     a Host header field, the host is determined by the Host header
     field value.

   3. If the host as determined by rule 1 or 2 is not a valid host on
     the server, the response MUST be a 400 (Bad Request) error message.

   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
   attempt to use heuristics (e.g., examination of the URI path for
   something unique to a particular host) in order to determine what
   exact resource is being requested.

5.3 Request Header Fields

   The request-header fields allow the client to pass additional
   information about the request, and about the client itself, to the
   server. These fields act as request modifiers, with semantics
   equivalent to the parameters on a programming language method
   invocation.

       request-header = Accept                   ; Section 14.1
                      | Accept-Charset           ; Section 14.2
                      | Accept-Encoding          ; Section 14.3
                      | Accept-Language          ; Section 14.4
                      | Authorization            ; Section 14.8
                      | Expect                   ; Section 14.20
                      | From                     ; Section 14.22
                      | Host                     ; Section 14.23
                      | If-Match                 ; Section 14.24
                      | If-Modified-Since        ; Section 14.25
                      | If-None-Match            ; Section 14.26
                      | If-Range                 ; Section 14.27
                      | If-Unmodified-Since      ; Section 14.28
                      | Max-Forwards             ; Section 14.31
                      | Proxy-Authorization      ; Section 14.34
                      | Range                    ; Section 14.35
                      | Referer                  ; Section 14.36
                      | TE                       ; Section 14.39
                      | User-Agent               ; Section 14.43

   Request-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields MAY be given the semantics of request-
   header fields if all parties in the communication recognize them to
   be request-header fields. Unrecognized header fields are treated as
   entity-header fields.

14.23 Host

   The Host request-header field specifies the Internet host and port
   number of the resource being requested, as obtained from the original
   URI given by the user or referring resource (generally an HTTP URL,
   as described in section 3.2.2). The Host field value MUST represent
   the naming authority of the origin server or gateway given by the
   original URL. This allows the origin server or gateway to
   differentiate between internally-ambiguous URLs, such as the root "/"
   URL of a server for multiple host names on a single IP address.

       Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

   A "host" without any trailing port information implies the default
   port for the service requested (e.g., "80" for an HTTP URL). For
   example, a request on the origin server for
   <http://www.w3.org/pub/WWW/> would properly include:

       GET /pub/WWW/ HTTP/1.1
       Host: www.w3.org

   A client MUST include a Host header field in all HTTP/1.1 request
   messages . If the requested URI does not include an Internet host
   name for the service being requested, then the Host header field MUST
   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
   request message it forwards does contain an appropriate Host header
   field that identifies the service being requested by the proxy. All
   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
   status code to any HTTP/1.1 request message which lacks a Host header
   field.

   See sections 5.2 and 19.6.1.1 for other requirements relating to
   Host.

19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
         Addresses

   The requirements that clients and servers support the Host request-
   header, report an error if the Host request-header (section 14.23) is
   missing from an HTTP/1.1 request, and accept absolute URIs (section
   5.1.2) are among the most important changes defined by this
   specification.

   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
   addresses and servers; there was no other established mechanism for
   distinguishing the intended server of a request than the IP address
   to which that request was directed. The changes outlined above will
   allow the Internet, once older HTTP clients are no longer common, to
   support multiple Web sites from a single IP address, greatly
   simplifying large operational Web servers, where allocation of many
   IP addresses to a single host has created serious problems. The
   Internet will also be able to recover the IP addresses that have been
   allocated for the sole purpose of allowing special-purpose domain
   names to be used in root-level HTTP URLs. Given the rate of growth of
   the Web, and the number of servers already deployed, it is extremely
   important that all implementations of HTTP (including updates to
   existing HTTP/1.0 applications) correctly implement these
   requirements:

      - Both clients and servers MUST support the Host request-header.

      - A client that sends an HTTP/1.1 request MUST send a Host header.

      - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
        request does not include a Host request-header.

      - Servers MUST accept absolute URIs.

Comment 6

[leger]

Resetting QA contact from leger.

Comment 7

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 8

[davew-bugz2]

This isn't a HTTP/1.1 issue, Mozilla already supports the host: header. However
Mozilla sends all HTTP headers in lower case, and some servers are sensitive to
this. Compare results of http://common.starflung.com/headers.php3 in Mozilla and
Navigator.

Apache is not sensitive to this but AOLserver is among others. See
http://davew.people.starflung.com/ - correct page (as viewed by navigator)
has a while background, incorrect one has a black background.

In the M12 source, you can fix this bug by correcting the case in line 66
of netwerk/protocol/http/src/nsHTTPAtomList.h :

HTTP_ATOM(Host,                      "Host")

but I am not sure that this is the best way to solve this....

Comment 9

[Warren Harris]

Maybe a dup of bug 19196.

Comment 10

[Warren Harris]

*** Bug 23550 has been marked as a duplicate of this bug. ***

Comment 11

[Gagan]

Fix checked in. Was happening because of lower case "Host:" header. See bug
20814 for more details.

Comment 12

[Tom Everingham]

verified