You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@hotwired.com> on 1996/10/01 08:47:19 UTC
Re: more problems with Host:'s
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 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/