Received: (from majordom@localhost)
          by hyperreal.com (8.8.4/8.8.4)
	  id OAA07021; Wed, 23 Apr 1997 14:40:07 -0700 (PDT)
Received: (from gnats@localhost)
          by hyperreal.com (8.8.4/8.8.4)
	  id OAA06922; Wed, 23 Apr 1997 14:40:02 -0700 (PDT)
Date: Wed, 23 Apr 1997 14:40:02 -0700 (PDT)
Message-Id: <199704232140.OAA06922@hyperreal.com>
To: apache-bugdb@apache.org
Cc: apache-bugdb@apache.org
From: Brett McCormick <brett@speedy.speakeasy.org>
Subject: Re: os-osf/463: virtualhost support functionally broken
Reply-To: Brett McCormick <brett@speedy.speakeasy.org>
Sender: apache-bugdb-owner@apache.org
Precedence: bulk

The following reply was made to PR os-osf/463; it has been noted by GNATS.

From: Brett McCormick <brett@speedy.speakeasy.org>
To: Dean Gaudet <dgaudet@arctic.org>
Subject: Re: os-osf/463: virtualhost support functionally broken
Date: Wed, 23 Apr 1997 14:36:28 -0700 (PDT)

 
 
 It is defined as 0xffffffff.
 inet_addr returns -1, heres the prototype:
   unsigned long    inet_addr __P((const char *));
 
 So, it would appear the problem is in my systems header files.
 Heh, the man page for inet_addr says:
 
 RETURN VALUES
 
   Upon successful completion, the inet_addr() function returns an equivalent
   network byte-ordered address integer.  Otherwise, it returns (in_addr_t)-1.
 
 except, inet_addr("foo") != (in_addr_t) -1
 
 I'll try changing it to use inet_network, but again, these functions
 take string ip addresses, whereas I'm using hostnames..
 
 Now that I think about it, I'm not even sure if 1.1.3 works out of the
 box..
 
 On Wed, 23 April 1997, at 14:19:22, Dean Gaudet wrote:
 
 > Is INADDR_NONE actually defined as -1 or as 0xffffffff ?  You've said both
 > below.  Does inet_addr actually return (unsigned)-1 on error or
 > INADDR_NONE?  What is inet_addr prototyped as? 
 > 
 > Isn't (unsigned long) the same as (unsigned) on the alpha?  Or is unsigned
 > a 32-bit quantity?
 > 
 > Can you try changing it to use inet_network instead of inet_addr? 
 > 
 > BTW, there is no portable solution to this as far as I can tell so far. 
 > I'll have to dig through mail archives to find the original change to
 > unsigned long. 
 > 
 > Dean
 > 
 > On Wed, 23 Apr 1997, Brett McCormick wrote:
 > 
 > > 
 > > Well, in this case we've got a hostname, so inet_{addr,network} will
 > > return -1.  I don't know if OSF if DGUX..  It doesn't seem to be set
 > > by cpp, though.  My feeling is that it's not.
 > > 
 > > On Wed, 23 April 1997, at 13:52:59, Dean Gaudet wrote:
 > > 
 > > > What does inet_network return?  Hasn't OSF become DGUX?
 > > > 
 > > > Dean
 > > > 
 > > > On Wed, 23 Apr 1997, Brett McCormick wrote:
 > > > 
 > > > > 
 > > > > Fairly certain.  Here's where the problem lies: inet_addr returnes -1
 > > > > (INADDR_NONE) on failure, which gets assigned to my_addr (unsigned
 > > > > long int).  That is then compared to INADDR_NONE (0xffffffff), which
 > > > > isn't casted to a long int.  So, -1 != 0xffffffff..  I suppose the
 > > > > correct fix would be to leave DEFAULT_VHOST_ADDR with the 'ul' at the
 > > > > end, and then cast INADDR_NONE to unsigned long in the comparison.
 > > > > 
 > > > >     } else if(
 > > > > #ifdef DGUX
 > > > >             ( my_addr = inet_network(w) )
 > > > > #else
 > > > >             ( my_addr = inet_addr(w) )
 > > > > #endif
 > > > >             != INADDR_NONE ) {
 > > > >         is_an_ip_addr = 1;
 > > > >     }
 > > > > 
 > > > > There are no errors starting up, and here are my virtualhost lines:
 > > > > 
 > > > > <Virtualhost www.prorental.com>
 > > > > DocumentRoot /usr/local/apache/httpd/sites/prorental/docs
 > > > > </VirtualHost>
 > > > > 
 > > > > <Virtualhost www.hedgescellars.com>
 > > > > DocumentRoot /usr/local/apache/httpd/sites/hedgescellars/docs
 > > > > </VirtualHost>
 > > > > 
 > > > > No matter what i ask for (localhost, www.prorental.com,
 > > > > www.hedgescellars.com) I get www.prorental.com..
 > > > > 
 > > > > On Wed, 23 April 1997, at 13:01:08, Dean Gaudet wrote:
 > > > > 
 > > > > > This code was changed to use an unsigned long specifically *because* of
 > > > > > OSF/1 and the alpha chip.  Are you absolutely sure that this is the
 > > > > > problem?  If we change it back it's likely to break the config of the
 > > > > > person that asked us to change it to a long.
 > > > > > 
 > > > > > Are there any errors while starting up? 
 > > > > > 
 > > > > > Can you send me the <VirtualHost> lines from your config?
 > > > > > 
 > > > > > Dean
 > > > > > 
 > > > > > On Wed, 23 Apr 1997, Brett McCormick wrote:
 > > > > > 
 > > > > > > 
 > > > > > > 	The contract type is `' with a response time of 3 business hours.
 > > > > > > 	A first analysis should be sent before: Wed Apr 23 14:00:01 PDT 1997
 > > > > > > 
 > > > > > > 
 > > > > > > >Number:         463
 > > > > > > >Category:       os-osf
 > > > > > > >Synopsis:       virtualhost support functionally broken
 > > > > > > >Confidential:   no
 > > > > > > >Severity:       critical
 > > > > > > >Priority:       medium
 > > > > > > >Responsible:    apache (Apache HTTP Project)
 > > > > > > >State:          open
 > > > > > > >Class:          sw-bug
 > > > > > > >Submitter-Id:   apache
 > > > > > > >Arrival-Date:   Wed Apr 23 11:20:01 1997
 > > > > > > >Originator:     brett@speakeasy.org
 > > > > > > >Organization:
 > > > > > > apache
 > > > > > > >Release:        1.2b8
 > > > > > > >Environment:
 > > > > > > Digital Unix (OSF/1) 4.0, gcc 2.7.2.1
 > > > > > > >Description:
 > > > > > > Virtualhosts do not operate correctly.  The first virtualhost (and not the main
 > > > > > > server) serves all requests.  This is due to get_addresses storing the ip addr
 > > > > > > in a long int, which on an alpha is 64bit.  DEFAULT_VHOST_ADDR is also specified
 > > > > > > as a long.
 > > > > > > >How-To-Repeat:
 > > > > > > just try to use virtualhosts on a platform with 64bit longs
 > > > > > > >Fix:
 > > > > > > change the type of my_addr in get_addresses (http_config.c) to a 32-bit type.
 > > > > > > change the definition of DEFAULT_VHOST_ADDR to be 32-bit (i don't think this
 > > > > > > is neccesary, but it might be)
 > > > > > > >Audit-Trail:
 > > > > > > >Unformatted:
 > > > > > > 
 > > > > > > 
 > > > > > > 
 > > > > > 
 > > > > 
 > > > 
 > > 
 >