ServerPath
ServerPath path
Virtual host
In HTTP 1.1 you can map several hostnames to the same IP address, and
the browser distinguishes between them by sending the
Host header. But it was thought there would be a
transition period during which some browsers still used HTTP 1.0 and
didn’t send the Host
header.[5] So
ServerPath lets the same site be accessed through
a path instead.
It has to be said that this directive often doesn’t
work very well because it requires a great deal of discipline in
writing consistent internal HTML links, which must all be written as
relative links to make them work with two different URLs. However, if
you have to cope with HTTP 1.0 browsers that don’t
send Host headers when accessing virtual sites,
you don’t have much choice.
For instance, suppose you have site1.example.com and site2.example.com mapped to the same IP address (let’s say 192.168.123.2), and you set up the httpd.conf file like this:
<VirtualHost 192.168.123.2> ServerName site1.example.com DocumentRoot /usr/www/APACHE3/site1 ServerPath /site1 </VirtualHost> <VirtualHost 192.168.123.2> ServerName site2.example.com DocumentRoot /usr/www/APACHE3/site2 ServerPath /site2 </VirtualHost>
Then an HTTP 1.1 browser can access the two sites with URLs http://site1.example.com / and http://site2.example.com /. Recall that HTTP 1.0 can only distinguish between sites with different IP addresses, so both of those URLs look the same to an HTTP 1.0 browser. However, with the previously listed setup, such browsers can access http://site1.example.com /site1 and http://site1.example.com /site2 to see the two different sites (yes, we did mean site1.example.com in the latter; it could have been site2.example.com in either, because they are the same as far as an HTTP 1.0 browser is concerned).
[5] Note that this transition period was almost
over before it started because many browsers sent the
Host header even in HTTP 1.0 requests. However, in
some rare cases, this directive may be useful.