www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@hyperreal.org>
Subject Re: mod_env/2256: SetEnv can not over ride variables like SERVER_NAME, HTTP_HOST, etc
Date Wed, 20 May 1998 13:50:02 GMT
The following reply was made to PR mod_env/2256; it has been noted by GNATS.

From: Brian Behlendorf <brian@hyperreal.org>
To: Simon Burr <simonb@uk.uu.net>
Cc: apbugs@Apache.Org
Subject: Re: mod_env/2256: SetEnv can not over ride variables like SERVER_NAME, HTTP_HOST,
etc
Date: Wed, 20 May 1998 06:42:46 -0700 (PDT)

 On Wed, 20 May 1998, Simon Burr wrote:
 > brian@hyperreal.org said
 > [Valid stuff snipped]
 > 
 > The problem is that the public facing IP address of the site is not
 > going to be the same as the IP address of the vhost on the backend.
 > I'm limited in what I can say (ick :(, but I can say that a browser
 > isn't going to be making the actual request to the web server - an
 > accelerator is going to be on the browsers behalf. 
 
 Sure, reverse proxying.  I've set up things like this.
 
 > The result of this
 > is that the browser does indeed send "web2.syseng.uk.uu.net" in the
 > Host: header, but the web server dealing with the request is going
 > to see "web2-real.syseng.uk.uu.net" in the Host: header of the request
 > that reaches it. 
 
 True.  Then you just need to ask yourself why your CGI script needs to
 rely upon HTTP_HOST and not some other variable.
 
 > To get the vhosting working I need to put the
 > web2-real bit in the ServerName... 
 
 You shouldn't need it.  I was incorrect when I stated that ServerName
 needed to resolve to anything in particular - it doesn't, I just checked. 
 Yes, it is the name that gets inserted when redirects are created, and
 when it goes to log, and in the CGI env, but that's about it really. Have
 a ServerAlias for "web2-real"  and the vhost definition will accept the
 right requests. 
 
 > I wish that I didn't have to over ride what is held in SERVER_NAME
 > and HTTP_HOST, but in our situation - a large scale mass web hosting
 > system - we're restricted in what we can do :(
 
 Are these third-party CGI scripts to which you don't have access or
 control over source that are relying upon HTTP_HOST?  It's just a very
 strange thing for a CGI script to be bothering with, what with
 virtualhosting being handled in the server.
 
 	Brian
 
 
 

Mime
View raw message