httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: No HOST header solutions?
Date Sat, 01 Jun 1996 23:35:07 GMT

(catching up, seems like I'm in a perpetual catch-up state these days)

The recommendation in host.html is alright with me - every solution which 
tries to accomodate old browsers is going to have some ugliness 
associated with it unfortunately.  The double-indexing problem is 
unfortunate, but I consider that less unfortunate than having URLs like as the *mandatory* URL format.  Still, 
there are problems with that solution - there are cases where references 
can't be relative, at least to the document root, i.e. <!--#include 
virtual="/footer.html" --> which is much easier to maintain than if the 
number of "../"'s had to be maintained.  Also, DOCUMENT_ROOT is pretty 
significant to some scripts.

For some of the content on hyperreal (such as the Low Res Film Festival, I'll probably use just the solution 
described in Alexei's document.  But for Organic clients we probably 
won't use non-IP vhosts until 95% of the requests coming in have a Host: 
header attached, with the default page then being "I see you browser 
doesn't support Host:.  Here are the browsers which do support it...".  
Of course, if we can make sure Host: header support in the Apache proxy 
modules is correct then we can tell people to install our proxy server 
too. :)

> Yep, it could. Here's a patch. It adds a new directive, ServerPath,
> which lets you do this (to continue with our example):
> <VirtualHost>
> ServerName
> ServerPath /apache
> DocumentRoot /usr/web/apache
> </VirtualHost>
> Then, therefore will get you the Apache
> pages, regardless of whether or not the client supports Host.
> It also adds a ServerRedirect command which would, if you added
> "ServerRedirect On" to the above entry, cause a (Host-header included)
> request for (and its member documents) to be
> redirected to This solves the
> double-mapping problem, and the relative link problem, since all links
> can now be of the longer form, but if your browser sends Host:, you
> can still type in all the shorter ones, and advertise them on teevee
> or whatever.

I think this is something that belongs in CGI land instead of inside the 
server, sincethis is really only an issue for the request for the root 
object (, and one could use index.cgi to look at 
HTTP_HOST and decide where to redirect people to.  This would have to go 
into the core, right?  If it were a module I'd be less adamant about not 
wanting to put stopgap solution cruft in the server.

The situation in which Alexei's solution is needed is one where I decide 
to move from being an IP-based VH to a Host:-based VH, and 
want to make sure that for most browsers gets 
redirected to  I don't consider 
needing to support old VH's for a stopgap solution as a priority, since 
as Rob said, that's spilt milk. 


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--  |  We're hiring!

View raw message