httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: bug o' the week
Date Sat, 23 Aug 1997 00:41:05 GMT
I'm sorry, this makes me puke.  Absolutely puke. 

I hereby resign as the defacto manager of the vhost code.  It is utterly
broken in 1.1, it is utterly broken in 1.2.  I have tried to clean it up
SEMANTICS in 1.3.  It's still not perfect but it has far fewer gotchas

Neither the 1.1 nor the 1.2 code work as you describe Alexei.  Go check
for yourself, and remember while you're at it that you should try every
single permutation of <VirtualHost> sections, because ORDER IS VERY
IMPORTANT, what works in one order will not work at all in another order.

I'm tired of this issue. I propsed a clear syntax for post 1.2, Roy also
independantly proposed the same syntax.  I backed off from implementing
it because I felt resistance.  Maybe if others go try to walk through
this code and see how lame and ambiguous our syntax is they'll understand
why I am being hardnosed about this.

In 1.3 a host is either an ip-vhost or a name-vhost, or the main server. 
It does not pretend to be one or the other.

In 1.1 and 1.2 any request coming in on the main server address can reach
any host, ip-vhost or name-vhost alike.  This is a bug in my opinion.
Consider and on the same machine,
remember that "Host: www" is a valid header, then imagine two different
configs in which one is the main server and the other is an ip-vhost.

In 1.1 and 1.2 any request coming in an ip-vhost address can possibly reach
any other vhost, depending on the ordering of the statements in the file.

Alexei you're saying that this is a feature: 

ServerName A

ServerName B

(where neither and are main server addresses)

% telnet
GET / HTTP/1.0
Host: B

Is a request against B.  Sorry, no, that's a bug.  1.2 might let you do
that, or you might need to reorder A and B to see the bug.  But it's
definately there.  And it's there in 1.1 as well. 

I completely agree that it is worthwhile to have multiple distinct pools of
name-based vhosts.  I do not agree in any cross over of pools.  I do not
agree with implementing this with our current syntax.  It is just not
obvious to the user what the hell is happening.  Search the archives
for my proposed syntax which disambiguates this and gives multiple
name-vhost pools as a feature.

Now when you're done thinking about all of that throw in a few :8080s
and :80s in there, then tell me it's not fucked.


On Fri, 22 Aug 1997, Alexei Kosut wrote:

> On Fri, 22 Aug 1997, Dean Gaudet wrote:
> > We only support name-based hosts for the main server address, and then it
> > doesn't matter which main server address you use, they're all treated the
> > same.  So unless A and B are both main server addresses then this isn't a
> > valid configuration.
> > 
> > The fact that it might have done something in 1.2 is a bug.  It's the bug
> > whereby and host, not just name-vhosts, can be reached by telnetting to a
> > main server address and using Host: foobar. 
> Whoa.... since when did this feature turn into a bug? Make no mistake
> about it, the ability to use virtual host IP addres for name-based hosts
> was an explicit *feature* I put into 1.1 when I wrote the Host: code.
> Explanation: Let's say I'm in charge of serving virtual hosts for two
> companies, who are entirely seperate, except that they have me do their
> web hosting. Imagine that each of them has ten domains they want to
> serve. I can't get twenty IP addresses, so I want to use name-based
> virtual hosts. But a chunk of the people accessing the site use browsers
> that don't support Host:, and I want them to go to the main page of each
> of the companies if they try to access one of the other nine servers on
> each, where they can find ServerPath-based links to wherever they're
> going.
> What I want to do is get two IP addresses, give company A's ten names to
> one IP, and company B's ten names to the other IP. I want someone going
> to "" who doesn't have Host to end up at "", and
> someone going to "" to end up at ""
> So therefore, I use DNS to set * to one IP address, and * to
> the other. I should then be able to use <VirtualHost> on all twenty
> addresses, and have it all work.
> -- Alexei Kosut <>

View raw message