Re: No HOST header solutions?

[Brian Behlendorf <br...@organic.com>]

(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 
http://www.apache.org/apache/ 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, 
http://www.hyperreal.com/lowres/) 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 www.apache.org>
> ServerName www.apache.org
> ServerPath /apache
> DocumentRoot /usr/web/apache
> </VirtualHost>
> 
> Then, therefore http://www.apache.org/apache/ 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 http://www.apache.org/ (and its member documents) to be
> redirected to http://www.apache.org/apache/. 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 (http://www.apache.org/), 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 www.apache.org from being an IP-based VH to a Host:-based VH, and 
want to make sure that for most browsers http://www.apache.org/docs/ gets 
redirected to http://www.apache.org/apache/docs/.  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. 

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  |  We're hiring!  http://www.organic.com/Home/Info/Jobs/

Re: No HOST header solutions?

[Brian Behlendorf <br...@organic.com>]

On Sat, 1 Jun 1996, Alexei Kosut wrote:
> Some of it has to go in the core, yeah. The reson for that is so that
> you can identify the correct virtual host, something you can't do from
> a module or, especially, from a CGI script. This is the main
> disadvantage with the approach in host.html using Alias, and was what
> Rob Hartill was complaining about.
>
> Using the Alias approach, with non-Host-sending browsers, the requests
> end up being in the main server's config setup, not the virtual
> server's. So if you have seperate log files, they end up in the wrong
> place. Similarly with redirects and error messages and all that other
> fun stuff that can't be set per-directory.

There are other things such an infrastructure should probably support for
people to really trust it - setting the DOCUMENT_ROOT variable to the
vhost's, modifying paths relative to docroot in parsed HTML files and imap
files, etc.  It just feels like the slippery slope, that 
if we make the implicit promise that this will "work", there's a lot of 
extra cruft that will end up in the server because people rely on this.  

It's not hard to write a perl tool which will pluck out requests for 
/vhost/* in the original server's logfiles, strip off the "/vhost" from 
the object name in the request, and merge it into the vhost's logfiles.  
it's also not hard to write a perl tool to take <VirtualHost> directives 
and map them into a <Location> or <Directory> section, too.  

I'm just in a really big KISS streak recently, and while I don't care as 
much about cruft being added to modules, cruft in the core *must* be 
highly justified.  I can definitely see how doing so here alleviates 
certain inconveniences, but I'd rather see if there's out-of-band 
solutions.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  |  We're hiring!  http://www.organic.com/Home/Info/Jobs/

Re: No HOST header solutions?

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Sat, 1 Jun 1996, Brian Behlendorf wrote:

> 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 (http://www.apache.org/), 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.

Some of it has to go in the core, yeah. The reson for that is so that
you can identify the correct virtual host, something you can't do from
a module or, especially, from a CGI script. This is the main
disadvantage with the approach in host.html using Alias, and was what
Rob Hartill was complaining about.

Using the Alias approach, with non-Host-sending browsers, the requests
end up being in the main server's config setup, not the virtual
server's. So if you have seperate log files, they end up in the wrong
place. Similarly with redirects and error messages and all that other
fun stuff that can't be set per-directory.

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/
 
      "War does not determine who is right, only who is left."