httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] Problem with DynDns and Apache Virtual Hosts
Date Thu, 09 Oct 2008 13:03:01 GMT
Bartek Śiwy Siwek wrote:

> I'll do that. Hoever I still don't understand why the request to a second vhost end up
redirected to first.
I think that you are getting confused between different steps of what 
happens (and it is quite easy to get confused, because there are many 
steps).  So you need to really look at each level individually, 
step-by-step, and try to figure out where the problem really is.
The point is, at this moment it is not sure that it is an Apache 
problem, or a DNS problem, or a router problem, or anything else.
You can start from one end, or from the other, but you have to be 
systematic about it, otherwise you will never solve it.

I'll try to help, starting from the last level, Apache and VirtualHosts.

1) a HTTP request comes into your server, if the client sent it *to the 
IP address* of your Apache host.
Not to the *name* of the server or any virtual host, to the IP address.
You should only continue if you really understand this fully.

2) when the HTTP request comes into the server, it looks like this :

GET / HTTP/1.1

There are 2 lines :
line 1 is the HTTP request
line 2 is an additional parameter for the request
So, the name of the server to which the client wants to talk, is an 
additional parameter "Host:" in the request, but it is not that name 
that made it so that the request arrived at this host.
I'll explain that later.

3) Now Apache has the request.
It looks at the Host: parameter, and sees that it says 
Apache then looks at each of its VirtualHost sections, to see if one of 
them matches that name.
If it finds one, then it "takes the personality" of that VirtualHost, 
and answers the request.
If it does not find any VirtualHost that matches the name, then it takes 
the personality of the first VirtualHost that it finds in the Apache 
configuration file, and answers the request as that one.
That is why this first VirtualHost is known as "the default Virtual 
Host".  It is just because, if Apache cannot find the "correct" Virtual 
Host, it will use this first one.

I will repeat this, so that there is no doubt :
No matter where the connection comes from, and no matter what the 
request says in line 2,

Now, how does the client know, that when it wants to get the content of 
the URL "", it needs to connect 
via TCP/IP to the host with address, on port 80 ?

That's a matter of name resolution, or DNS.
The client (in this case the browser), will ask its underlying operating 
system to translate "" into an IP 
address.  And whatever the OS answers, the client will believe it.

4) So the client asks, and gets the IP address "".
Now it connects to the server at, port 80, and sends the 
request :
GET / HTTP/1.1
and Apache responds like in 3 above.

The points to really get here :
a) if Apache gets a connection, and on that connection it gets a request 
that looks like
GET / HTTP/1.1
then it will always handle this request, as described above.
Apache has no idea how the client got his IP address, before sending 
this request.  It may be that the client DNS was wrong, and gave it a 
wrong IP address for "", but Apache knows 
nothing of that.

b) if anything in-between the client and the server is intercepting that 
connection, and for some reason directing it somewhere else than it 
should, it will end up on another host, which maybe does not know the 
VirtualHost named "", and will thus 
respond with its default VirtualHost.

c) If your client is getting a 301 response at some point, then it means 
that something sent that response.
Apache by itself will not send back a 301 response, unless you 
explicitly tell it to do that somewhere in the configuration.
So if it is not Apache, it is something else that is in-between your 
client and Apache.
A proxy server ? a firewall ?

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message