You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@organic.com> on 1996/09/28 04:00:42 UTC
more problems with Host:'s
Something is really screwy here.
Go to http://hyperreal.com/ through Netscape: great, looks gorgeous
telnet to hyperreal.com port 80, and issue a
GET / HTTP/1.0
with no other headers, and I get the home page for one of the Host:-header
based home pages, www.grooveneedle.com, which happens to be the last
Host:-header-based vhost section in my httpd.conf. If I use a Host: header
everything works as it should. Anyone have any ideas?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: more problems with Host:'s
Posted by Dean Gaudet <dg...@hotwired.com>.
Consider virtualhost_section():
s->next = main_server->next;
main_server->next = s;
And this config frag:
<VirtualHost A>
</VirtualHost>
<VirtualHost B>
</VirtualHost>
<VirtualHost C>
</VirtualHost>
Let D be the "default" server... or main_server.. or whatever you want
to call it (http_main variable server_conf). Then the ->next chain looks
like this: D, C, B, A.
Suppose C, B, and A all have the same ip address. Then find_virtual_host
will return C's server_rec. So check_serverpath and check_hostalias
will check the appropriate data for B and A... no need to check C
because if B and A don't match then it'll just stay at C anyhow.
But I'd like to state again that I haven't looked at check_hostalias() too
deeply... I'm certain that check_serverpath starting at r->server->next
works, and so would starting at r->server at the expense of some unneeded
comparison.
It was a lot less confusing before name-vhosts... I think it's especially
confusing because the hosts are dealt with in reverse config-file order.
This is one of the reasons I proposed a rethink of the syntax for it
all that would lay out the selection order in detail.
Dean
P.S. BTW, the suggestion of "ServerPath /" only works if you don't want
to use ServerPath for any other name-vhost, otherwise it'll always go
to the "serverpath /" server when there's no Host: header.
In article <ho...@sierra.zyzzyva.com>,
Randy Terbush <ne...@hyperreal.com> wrote:
>> It doesn't seem screwy to me (mind you, I'm looking at 1.1.1 code):
>
>I just glanced at the 1.1.1 code, and there is little (if any) difference.
>
>With my config file layout, the Zyzzyva server is consistently last
>in the filesystem, and seems to have been the only server effected.
>
>By initializing the loop below to r->server->next, the condition to
>exit this loop is met for the last server in the list before even
>entered. This is definitely as Brian describe with config file order
>being the key. Since the server list is not circular, I don't see
>how this could work.
>
>The code: (1.2)
>
>
> for (s = r->server->next; s; s = s->next) {
> char *names = s->names;
>
> if ((!strcasecmp(host, s->server_hostname)) && (port == s->port)) {
> r->server = r->connection->server = s;
> if (r->hostlen && !strncmp(r->uri, "http://", 7)) {
> r->uri += r->hostlen;
> parse_uri(r, r->uri);
> }
> }
>
> if (!names) continue;
>
> while (*names) {
> char *name = getword_conf (r->pool, &names);
>
> if ((is_matchexp(name) && !strcasecmp_match(host, name)) ||
> (!strcasecmp(host, name))) {
> r->server = r->connection->server = s;
> if (r->hostlen && !strncmp(r->uri, "http://", 7)) {
> r->uri += r->hostlen;
> r->proxyreq = 0;
> }
> }
> }
> }
>
>> www.hyperreal.com IN A 204.152.144.36
>> www.grooveneedle.com IN A 204.152.144.36
>>
>> <virtualhost>s are stacked, so the last in the file is the first
>> match found. Unless the request has something to differentiate it --
>> which "GET / HTTP/1.0" doesn't -- you get the first match found in
>> find_virtual_server.
>>
>> Regarding the r->server->next in check_serverpath(), I don't see how
>> changing it to r->server affects anything other than performance. If
>> the if conditional succeeds it will set r->server = r->server.
>>
>> check_hostalias does other crud, so it's possible that starting at
>> r->server would have a different effect... but if you dig back through
>> read_request (caller of check_hostalias) and into read_request_line
>> you'll see it does similar crud.
>>
>> Anyhow, since check_serverpath() searches from last <virtualhost> to first,
>> if you put "ServerPath /" into hyperreal's <virtualhost> section it will
>> become the default.
>>
>> Dean
>>
>> In article <ho...@fully.organic.com>,
>> Brian Behlendorf <ne...@hyperreal.com> wrote:
>> >
>> >Something is really screwy here.
>> >
>> >Go to http://hyperreal.com/ through Netscape: great, looks gorgeous
>> >
>> >telnet to hyperreal.com port 80, and issue a
>> >
>> > GET / HTTP/1.0
>> >
>> >with no other headers, and I get the home page for one of the Host:-header
>> >based home pages, www.grooveneedle.com, which happens to be the last
>> >Host:-header-based vhost section in my httpd.conf. If I use a Host: header
>> >everything works as it should. Anyone have any ideas?
>> >
>> > Brian
>> >
>> >
>> >--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
>> >brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
>> >
>>
>
>
>
Re: more problems with Host:'s
Posted by Dean Gaudet <dg...@hotwired.com>.
In article <ho...@fully.organic.com>,
Brian Behlendorf <ne...@hyperreal.com> wrote:
>> - global Port becomes the default for any unspecified :port
>> - never select a server unless the ip is in the addrs list
>> (remember we have a bug here right now)
>> - never select a server unless the port matches
>> - servers appearing earlier in the config file override servers appearing
>> later if there is a conflict (presently it's opposite)
>
>I agree with 1 2 and 3, and with 4 with the caveat that I still think conflicts
>should be flagged as errors instead of ignored.
Cliff asked for those errors as well. I said they're not easy to
generate. Consider the case of two name-vhosts differentiated by some
wildcarded serveraliases. Unless you're referring to spamming the
error_log at run time when the conflict is detected.
Dean
Re: more problems with Host:'s
Posted by Brian Behlendorf <br...@organic.com>.
On 3 Oct 1996, Dean Gaudet wrote:
> Here's two suggested approaches to properly fix this:
>
> - add a port -1 which becomes the wildcard port
>
> - pass the global server_conf in as a parm to get_addresses and use it
> to set sar->host_port when the name has no :port tacked on.
> (You also probably should fix get_virthost_addr which get_addresses
> descended from when I did the multi-ip patch.) Leave 0 as the
> wildcard port.
>
> I'm partial to the second fix because I think of the global Port statement
> as meaning "pretend the HTTP specification says port N instead of 80".
Did anyone try this out yet? This section of the code is like martian
territory to me, but if I have to I'll dive into it.
> It has the implication that if a config looks like this:
>
> Port 1111
> <VirtualHost A>
> ...
> </VirtualHost>
> Port 2222
> <VirtualHost B>
> ...
> </VirtualHost>
>
> Then A and B will live on different ports. But I think this is intuitive.
I disagree. In my opinion order of directives in config files should be
completely insignificant; and multiple occurances of a directive which should
only appear once should be flagged as a non-fatal error but an error
nonetheless. </rant>
> Brian asked if we should sit down and rethink the whole server selection
> process... we should. But I doubt we can fit it in for 1.2. Here's
> my input:
>
> - global Port becomes the default for any unspecified :port
> - never select a server unless the ip is in the addrs list
> (remember we have a bug here right now)
> - never select a server unless the port matches
> - servers appearing earlier in the config file override servers appearing
> later if there is a conflict (presently it's opposite)
I agree with 1 2 and 3, and with 4 with the caveat that I still think conflicts
should be flagged as errors instead of ignored.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: more problems with Host:'s
Posted by Dean Gaudet <dg...@hotwired.com>.
In article <ho...@clotho.c2.org>,
<ne...@hyperreal.com> wrote:
>>
>> I think we need to find out why Alexei made that change in the first
>> place... is he around somewhere?
>
> There was a problem where port-based virtual hosts were
>causing a problem:
>
>Port 80
>Listen 80
>Listen 443
>[normal config]
>
><VirtualHost *:443>
>port 443 config
></VirtualHost>
>
> The port 443 config was used for port 80 connections.
Right, now I remember you and Ben talking about that and the patch was
something like this:
+ int port = (*r->hostname) ? atoi(r->hostname) : 80;
- int port = (*r->hostname) ? atoi(r->hostname) : 0;
A 0 port has the following meanings (depending on where in the code you are):
- any port
- the global Port (i.e. Port 80 in sameer's config)
- port 80
Which is beginning to sound pretty hopeless. I believe the fault was
in adding the "any port" meaning to it, which occured somewhere around
1.1. Specifically, I think the Listen directive brought in that meaning.
Here's two suggested approaches to properly fix this:
- add a port -1 which becomes the wildcard port
- pass the global server_conf in as a parm to get_addresses and use it
to set sar->host_port when the name has no :port tacked on.
(You also probably should fix get_virthost_addr which get_addresses
descended from when I did the multi-ip patch.) Leave 0 as the
wildcard port.
I'm partial to the second fix because I think of the global Port statement
as meaning "pretend the HTTP specification says port N instead of 80".
It has the implication that if a config looks like this:
Port 1111
<VirtualHost A>
...
</VirtualHost>
Port 2222
<VirtualHost B>
...
</VirtualHost>
Then A and B will live on different ports. But I think this is intuitive.
It breaks people using multiple Listens and expecting :* behaviour when
they don't specify any port.
Can someone try this? I'm way too busy... and am leaving for 3 weeks
starting monday. It should work since Brian said putting "Port 80" in
each of his vhosts made things work right.
Brian asked if we should sit down and rethink the whole server selection
process... we should. But I doubt we can fit it in for 1.2. Here's
my input:
- global Port becomes the default for any unspecified :port
- never select a server unless the ip is in the addrs list
(remember we have a bug here right now)
- never select a server unless the port matches
- servers appearing earlier in the config file override servers appearing
later if there is a conflict (presently it's opposite)
Dean
P.S. Anyone else love indirection like server_addr_rec ***paddr
in get_addresses? Pointer to pointer has a mathematical elegance.
I remember hating Pascal in school because linked list and tree
manipulations were needlessly complicated by the lack of an address-of
operator.
Re: more problems with Host:'s
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Mon, 30 Sep 1996, Dean Gaudet wrote:
> I think we need to find out why Alexei made that change in the first
> place... is he around somewhere?
Sort of. I just finished reading over 3000 mail messages, and my brain
is fizzled.
The answer to anything dealing with the check_hostalias() code is
usually "Don't ask. It's better you don't know." I rewrote that code
three or four times originally, and it just got worse, as full-URI
checking and ServerAlias and ServerPath and HTTP/1.1-compatibility and
who-knows-what-else was added.
I just keep thinking that life would be so much easier if I had stuck
to my original plan and used a seperate <HostAlias> section, instead
of sticking it onto <VirtualHost> (ever wonder why the function is
called check_hostalias?) Brian talked me into the latter (aha! it's
all his fault,) but I'm not quite sure it was a good idea. Too late
now, though, I suppose.
I'll try to take a better look at all this tomorrow (er... today).
*sigh*
--
________________________________________________________________________
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/
Re: more problems with Host:'s
Posted by Dean Gaudet <dg...@hotwired.com>.
I think we need to find out why Alexei made that change in the first
place... is he around somewhere?
Dean
In article <ho...@fully.organic.com> you write:
>On 30 Sep 1996, Dean Gaudet wrote:
>> Notice that the default for the local variable ports was changed from
>> 0 to 80. But then the if statement:
>>
>> if (port && (port != r->server->port))
>> return;
>>
>> Is always going to return since r->server->port defaults to 0 when
>> no port is specified when configuring a virtualhost.
>>
>> Unfortunately this changed occured during Alexei's huge HTTP/1.1 commit
>> (revision 1.30 of http_protocol.c).
>>
>> What happens when you put Port 80 in each of your virtualhosts?
>
>Clarification: I'm testing this on a high-port, port 8001, and when I use
>
> <VirtualHost 204.152.144.36:8001>
>
>it doesn't work (requests for one name-vhost return another), but when I put
>
> <VirtualHost 204.152.144.36:80>
>
>things work as expected.
>
> Brian
>
>--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
>brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
>
Re: more problems with Host:'s
Posted by Brian Behlendorf <br...@organic.com>.
On 30 Sep 1996, Dean Gaudet wrote:
> Notice that the default for the local variable ports was changed from
> 0 to 80. But then the if statement:
>
> if (port && (port != r->server->port))
> return;
>
> Is always going to return since r->server->port defaults to 0 when
> no port is specified when configuring a virtualhost.
>
> Unfortunately this changed occured during Alexei's huge HTTP/1.1 commit
> (revision 1.30 of http_protocol.c).
>
> What happens when you put Port 80 in each of your virtualhosts?
Then everything works! That must be it.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: more problems with Host:'s
Posted by Brian Behlendorf <br...@organic.com>.
On 30 Sep 1996, Dean Gaudet wrote:
> Notice that the default for the local variable ports was changed from
> 0 to 80. But then the if statement:
>
> if (port && (port != r->server->port))
> return;
>
> Is always going to return since r->server->port defaults to 0 when
> no port is specified when configuring a virtualhost.
>
> Unfortunately this changed occured during Alexei's huge HTTP/1.1 commit
> (revision 1.30 of http_protocol.c).
>
> What happens when you put Port 80 in each of your virtualhosts?
Clarification: I'm testing this on a high-port, port 8001, and when I use
<VirtualHost 204.152.144.36:8001>
it doesn't work (requests for one name-vhost return another), but when I put
<VirtualHost 204.152.144.36:80>
things work as expected.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: more problems with Host:'s
Posted by Dean Gaudet <dg...@hotwired.com>.
Argh this code is a mess. I'm looking at check_hostalias, which appears
to have been modified between 1.1.1 and 1.2:
*** check_hostalias.111 Mon Sep 30 00:13:46 1996
--- check_hostalias.12 Mon Sep 30 00:14:12 1996
***************
*** 1,13 ****
! void check_hostalias (request_rec *r) {
char *host = getword(r->pool, &r->hostname, ':'); /* Get rid of port */
! int port = (*r->hostname) ? atoi(r->hostname) : 0;
server_rec *s;
if (port && (port != r->server->port))
return;
! if ((host[strlen(host)-1]) == '.') {
! host[strlen(host)-1] = '\0';
}
r->hostname = host;
--- 1,15 ----
! static void check_hostalias (request_rec *r) {
char *host = getword(r->pool, &r->hostname, ':'); /* Get rid of port */
! int port = (*r->hostname) ? atoi(r->hostname) : 80;
server_rec *s;
+ int l;
if (port && (port != r->server->port))
return;
! l = strlen(host)-1;
! if ((host[l]) == '.') {
! host[l] = '\0';
}
r->hostname = host;
***************
*** 15,22 ****
for (s = r->server->next; s; s = s->next) {
char *names = s->names;
! if ((!strcasecmp(host, s->server_hostname)) &&
! (!port || (port == s->port))) {
r->server = r->connection->server = s;
if (r->hostlen && !strncmp(r->uri, "http://", 7)) {
r->uri += r->hostlen;
--- 17,23 ----
for (s = r->server->next; s; s = s->next) {
char *names = s->names;
! if ((!strcasecmp(host, s->server_hostname)) && (port == s->port)) {
r->server = r->connection->server = s;
if (r->hostlen && !strncmp(r->uri, "http://", 7)) {
r->uri += r->hostlen;
Notice that the default for the local variable ports was changed from
0 to 80. But then the if statement:
if (port && (port != r->server->port))
return;
Is always going to return since r->server->port defaults to 0 when
no port is specified when configuring a virtualhost.
Unfortunately this changed occured during Alexei's huge HTTP/1.1 commit
(revision 1.30 of http_protocol.c).
What happens when you put Port 80 in each of your virtualhosts?
Dean
P.S. check_fulluri() will become a performance hog in the future if
all requests use "GET http://host/path/ HTTP/x.y" -- it will do a
DNS lookup on every hit to find out if host matches its ip. See
read_request_line(). It is a hog now on proxies since all requests
are of that form.
In article <ho...@fully.organic.com>,
Brian Behlendorf <ne...@hyperreal.com> wrote:
>
>Randy's patch (r->server->next ==> r->server) didn't change a thing. to "fix
>it" I had to place the vhost segment for what I was calling the "default"
>server at the end.
>
>Here's the relevant sections from my httpd.conf file. Hyperreal's primary
>address is 204.152.144.36.
>
> Port 8O
> ServerName www.hyperreal.com
> DocumentRoot /export/pub
>
><<These are the configs I am presuming would apply if a request to
>204.152.144.36 came without a Host: header!!>>
>
> <VirtualHost 204.152.144.36>
> ServerName www.grooveneedle.com
> .....
> </VirtualHost>
>
> <VirtualHost 204.152.144.36>
> ServerName dev.apache.org
> ...
> </VirtualHost>
>
> <VirtualHost 204.152.144.36>
> ServerName www.hyperreal.com
> Redirect /axiom http://www.hyperreal.com/music/labels/axiom
> ...(lots of stuff I want to ONLY apply to www.hyperreal.com)...
> </VirtualHost>
>
> <VirtualHost 204.152.144.38>
> ServerName www.apache.org
> ....
> </VirtualHost>
>
> etc...
>
>In order for www.hyperreal.com to come up as the host for requests without a
>Host: header, it must be the *last* of the 204.152.144.36 vhosts. Previously I
>had it as the *first*, and accesses were defaulting to dev.apache.org's vhost
>section. This is a change that happened recently, as in the last few weeks at
>the most.
>
>Now, THIS is where it gets interesting, and what is a real BUG compared to
>just being a confusing aspect of the current config situation. Let's say I
>move the vhost segment for www.apache.org in between www.grooveneedle.com and
>dev.apache.org. When I do that, EVERY request for dev.apache.org and
>www.hyperreal.com get shunted to www.grooveneedle.com. If I move the vhost
>segment for www.apache.org in between dev.apache.org and www.hyperreal.com, the
>www.grooveneedle.com and dev.apache.org work fine, but www.hyperreal.com gets
>shunted to dev.apache.org. It appears that only name-vhost segments before the
>first IP-vhost segment are matched!
>
>It looks like the ONLY acceptible config file format is
>
> VirtualHost name-vhost1
> VH name-vhost2
> ....
> VH default-server
> VH IP-vhost1
> VH IP-vhost2
>
>Etc. Anyone have evidence to the contrary? Does someone know the code well
>enough in this area to find the cause?
>
>On 29 Sep 1996, Dean Gaudet wrote:
>> It doesn't seem screwy to me (mind you, I'm looking at 1.1.1 code):
>>
>> www.hyperreal.com IN A 204.152.144.36
>> www.grooveneedle.com IN A 204.152.144.36
>>
>> <virtualhost>s are stacked, so the last in the file is the first
>> match found. Unless the request has something to differentiate it --
>> which "GET / HTTP/1.0" doesn't -- you get the first match found in
>> find_virtual_server.
>
>Okay, this is the crux of my misunderstanding/problem statement. I guess
>nowhere is the logic "if there's no Host header, default to the 'main' server
>on that IP number", and if that's the server's main IP number ("Port", outside
>of <vhost> segments), then it should bind to the same DocumentRoot which sits
>outside the <vhost> segments as well. In fact the logic should check that the
>vhost segment with ServerName set to the same as ServerName set outside any
><vhost> segment is the "default" server; presumably that was put there (as I
>did, and I know lots others do) to allow for certain configs to be scoped
>locally to the main server, not globally to all servers.
>
>> Anyhow, since check_serverpath() searches from last <virtualhost> to first,
>> if you put "ServerPath /" into hyperreal's <virtualhost> section it will
>> become the default.
>
>Or rearrange the order, as I did do. Neither this or the above suggestion are
>intuitive, nor were they required before sometime in the last two weeks.
>
> Brian
>
>--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
>brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
>
Re: more problems with Host:'s
Posted by Brian Behlendorf <br...@organic.com>.
Randy's patch (r->server->next ==> r->server) didn't change a thing. to "fix
it" I had to place the vhost segment for what I was calling the "default"
server at the end.
Here's the relevant sections from my httpd.conf file. Hyperreal's primary
address is 204.152.144.36.
Port 8O
ServerName www.hyperreal.com
DocumentRoot /export/pub
<<These are the configs I am presuming would apply if a request to
204.152.144.36 came without a Host: header!!>>
<VirtualHost 204.152.144.36>
ServerName www.grooveneedle.com
.....
</VirtualHost>
<VirtualHost 204.152.144.36>
ServerName dev.apache.org
...
</VirtualHost>
<VirtualHost 204.152.144.36>
ServerName www.hyperreal.com
Redirect /axiom http://www.hyperreal.com/music/labels/axiom
...(lots of stuff I want to ONLY apply to www.hyperreal.com)...
</VirtualHost>
<VirtualHost 204.152.144.38>
ServerName www.apache.org
....
</VirtualHost>
etc...
In order for www.hyperreal.com to come up as the host for requests without a
Host: header, it must be the *last* of the 204.152.144.36 vhosts. Previously I
had it as the *first*, and accesses were defaulting to dev.apache.org's vhost
section. This is a change that happened recently, as in the last few weeks at
the most.
Now, THIS is where it gets interesting, and what is a real BUG compared to
just being a confusing aspect of the current config situation. Let's say I
move the vhost segment for www.apache.org in between www.grooveneedle.com and
dev.apache.org. When I do that, EVERY request for dev.apache.org and
www.hyperreal.com get shunted to www.grooveneedle.com. If I move the vhost
segment for www.apache.org in between dev.apache.org and www.hyperreal.com, the
www.grooveneedle.com and dev.apache.org work fine, but www.hyperreal.com gets
shunted to dev.apache.org. It appears that only name-vhost segments before the
first IP-vhost segment are matched!
It looks like the ONLY acceptible config file format is
VirtualHost name-vhost1
VH name-vhost2
....
VH default-server
VH IP-vhost1
VH IP-vhost2
Etc. Anyone have evidence to the contrary? Does someone know the code well
enough in this area to find the cause?
On 29 Sep 1996, Dean Gaudet wrote:
> It doesn't seem screwy to me (mind you, I'm looking at 1.1.1 code):
>
> www.hyperreal.com IN A 204.152.144.36
> www.grooveneedle.com IN A 204.152.144.36
>
> <virtualhost>s are stacked, so the last in the file is the first
> match found. Unless the request has something to differentiate it --
> which "GET / HTTP/1.0" doesn't -- you get the first match found in
> find_virtual_server.
Okay, this is the crux of my misunderstanding/problem statement. I guess
nowhere is the logic "if there's no Host header, default to the 'main' server
on that IP number", and if that's the server's main IP number ("Port", outside
of <vhost> segments), then it should bind to the same DocumentRoot which sits
outside the <vhost> segments as well. In fact the logic should check that the
vhost segment with ServerName set to the same as ServerName set outside any
<vhost> segment is the "default" server; presumably that was put there (as I
did, and I know lots others do) to allow for certain configs to be scoped
locally to the main server, not globally to all servers.
> Anyhow, since check_serverpath() searches from last <virtualhost> to first,
> if you put "ServerPath /" into hyperreal's <virtualhost> section it will
> become the default.
Or rearrange the order, as I did do. Neither this or the above suggestion are
intuitive, nor were they required before sometime in the last two weeks.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: more problems with Host:'s
Posted by Dean Gaudet <dg...@hotwired.com>.
It doesn't seem screwy to me (mind you, I'm looking at 1.1.1 code):
www.hyperreal.com IN A 204.152.144.36
www.grooveneedle.com IN A 204.152.144.36
<virtualhost>s are stacked, so the last in the file is the first
match found. Unless the request has something to differentiate it --
which "GET / HTTP/1.0" doesn't -- you get the first match found in
find_virtual_server.
Regarding the r->server->next in check_serverpath(), I don't see how
changing it to r->server affects anything other than performance. If
the if conditional succeeds it will set r->server = r->server.
check_hostalias does other crud, so it's possible that starting at
r->server would have a different effect... but if you dig back through
read_request (caller of check_hostalias) and into read_request_line
you'll see it does similar crud.
Anyhow, since check_serverpath() searches from last <virtualhost> to first,
if you put "ServerPath /" into hyperreal's <virtualhost> section it will
become the default.
Dean
In article <ho...@fully.organic.com>,
Brian Behlendorf <ne...@hyperreal.com> wrote:
>
>Something is really screwy here.
>
>Go to http://hyperreal.com/ through Netscape: great, looks gorgeous
>
>telnet to hyperreal.com port 80, and issue a
>
> GET / HTTP/1.0
>
>with no other headers, and I get the home page for one of the Host:-header
>based home pages, www.grooveneedle.com, which happens to be the last
>Host:-header-based vhost section in my httpd.conf. If I use a Host: header
>everything works as it should. Anyone have any ideas?
>
> Brian
>
>
>--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
>brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
>