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...@arctic.org> on 1997/10/05 11:16:38 UTC

more vhost thoughts

1.

If a client connects to port X and gives "Host: foo:Y" where Y != X,
should the server reject the request? 

Right now my code does it's first pass using X (this is the pass which
determines which pool of name-vhosts to use, and it happens before headers
are read), then does the second pass using Y (this is when it checks the
hostname, and this is just how we always did it). 

The period of time between when the connection is opened and the request
headers are read is arbitrarily long, and there are error conditions that
can be generated.  The way my code is written right now, those errors will
be issued using the default server for the name-vhost pool.  (Present
behaviour issues the errors with the main server, which is essentially the
default server for the single name-vhost pool.) 

2.

The Port directive is a non-intuitive mess when applied to vhosts.  Consider:

    <VirtualHost 127.0.0.1>
	Port 8080
    </VirtualHost>

That's a vhost on port 80, which will issue redirects indicating port 8080.
Solution?

Dean


Re: more vhost thoughts

Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
> 
> 1.
> 
> If a client connects to port X and gives "Host: foo:Y" where Y != X,
> should the server reject the request?

Yes, it should.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: more vhost thoughts

Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
> 
> On Sun, 5 Oct 1997, Ben Laurie wrote:
> 
> > Marc Slemko wrote:
> > >
> > > On Sun, 5 Oct 1997, Dean Gaudet wrote:
> > >
> > > > 2.
> > > >
> > > > The Port directive is a non-intuitive mess when applied to vhosts.  Consider:
> > > >
> > > >     <VirtualHost 127.0.0.1>
> > > >       Port 8080
> > > >     </VirtualHost>
> > > >
> > > > That's a vhost on port 80, which will issue redirects indicating port 8080.
> > > > Solution?
> > >
> > > I am more concerned about the case where someone makes a vhost on a
> > > different port (eg. main server port 80, vhost 8080) and forget the Port
> > > directive.  I'm afraid I'm not entirely clear on what the Port directive
> > > does that can't be figured out by what port something is really on.
> >
> > Confuses me, too ... if I want to have hosts on two ports I usually do
> > something like:
> >
> > Port 80
> > Listen 81
> 
> You need a Listen 80 too, don't you?

Err, yeah.

> > <VirtualHost foo:81>
> > .
> > .
> > .
> > </VirtualHost>
> >
> > I still haven't figured out why I have to do the Listen (conceptually,
> > that is, rather than what the code does).
> 
> This one I can go for.  I like telling Apache explicitly what sockets it
> needs to open.  Ports are different, but without Listen Apache wouldn't
> know what IPs to listen to when you don't want it wildcarded.  Trying to
> guess that from the VirtualHost directive isn't possible.
> 
> Guessing the port is possible, but I prefer Apache guessing as little as
> possible.  We tried that with the VirtualHost directive for non-IP virtual
> hosts.

Hmmm ... the status quo is acceptable (though it might be nice to flag
virtual hosts that can't ever match coz of lack of Listening - would
save a lot of newbie grief, particularly when SSL gets into the picture
[this was my most FAed FAQ until I tweaked the sample files]).

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: more vhost thoughts

Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 5 Oct 1997, Ben Laurie wrote:

> Marc Slemko wrote:
> > 
> > On Sun, 5 Oct 1997, Dean Gaudet wrote:
> > 
> > > 2.
> > >
> > > The Port directive is a non-intuitive mess when applied to vhosts.  Consider:
> > >
> > >     <VirtualHost 127.0.0.1>
> > >       Port 8080
> > >     </VirtualHost>
> > >
> > > That's a vhost on port 80, which will issue redirects indicating port 8080.
> > > Solution?
> > 
> > I am more concerned about the case where someone makes a vhost on a
> > different port (eg. main server port 80, vhost 8080) and forget the Port
> > directive.  I'm afraid I'm not entirely clear on what the Port directive
> > does that can't be figured out by what port something is really on.
> 
> Confuses me, too ... if I want to have hosts on two ports I usually do
> something like:
> 
> Port 80
> Listen 81

You need a Listen 80 too, don't you?

> 
> <VirtualHost foo:81>
> .
> .
> .
> </VirtualHost>
> 
> I still haven't figured out why I have to do the Listen (conceptually,
> that is, rather than what the code does). 

This one I can go for.  I like telling Apache explicitly what sockets it
needs to open.  Ports are different, but without Listen Apache wouldn't
know what IPs to listen to when you don't want it wildcarded.  Trying to
guess that from the VirtualHost directive isn't possible.

Guessing the port is possible, but I prefer Apache guessing as little as
possible.  We tried that with the VirtualHost directive for non-IP virtual
hosts.


Re: more vhost thoughts

Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
> 
> On Sun, 5 Oct 1997, Dean Gaudet wrote:
> 
> > 2.
> >
> > The Port directive is a non-intuitive mess when applied to vhosts.  Consider:
> >
> >     <VirtualHost 127.0.0.1>
> >       Port 8080
> >     </VirtualHost>
> >
> > That's a vhost on port 80, which will issue redirects indicating port 8080.
> > Solution?
> 
> I am more concerned about the case where someone makes a vhost on a
> different port (eg. main server port 80, vhost 8080) and forget the Port
> directive.  I'm afraid I'm not entirely clear on what the Port directive
> does that can't be figured out by what port something is really on.

Confuses me, too ... if I want to have hosts on two ports I usually do
something like:

Port 80
Listen 81

<VirtualHost foo:81>
.
.
.
</VirtualHost>

I still haven't figured out why I have to do the Listen (conceptually,
that is, rather than what the code does).

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 994 6435|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 994 6472|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: more vhost thoughts

Posted by Dean Gaudet <dg...@arctic.org>.

On Sun, 5 Oct 1997, Marc Slemko wrote:

> On Sun, 5 Oct 1997, Dean Gaudet wrote:
> 
> > 2.
> > 
> > The Port directive is a non-intuitive mess when applied to vhosts.  Consider:
> > 
> >     <VirtualHost 127.0.0.1>
> > 	Port 8080
> >     </VirtualHost>
> > 
> > That's a vhost on port 80, which will issue redirects indicating port 8080.
> > Solution?
> 
> I am more concerned about the case where someone makes a vhost on a
> different port (eg. main server port 80, vhost 8080) and forget the Port
> directive.  I'm afraid I'm not entirely clear on what the Port directive
> does that can't be figured out by what port something is really on.

A virtual server's default Port setting is the same as the port on the
first address in the VirtualHost statement... and the port in that address
defaults to the same as the main server's...

So this config:

Port 8080

<VirtualHost 127.0.0.1>
ServerName foo
</VirtualHost>

Behaves "as expected" ... and you can change Port 8080 to whatever else
and get another working config.  This also behaves "as expected":

Port 8080

NameVirtualHost 127.0.0.1

<VirtualHost 127.0.0.1>
ServerName foo
</VirtualHost>

<VirtualHost 127.0.0.1>
ServerName bar
</VirtualHost>

Dean

(I'm speaking in terms of my current code base, although this is mostly
how HEAD currently functions anyhow)


Re: more vhost thoughts

Posted by Dean Gaudet <dg...@arctic.org>.

On Sun, 5 Oct 1997, Marc Slemko wrote:

> On Sun, 5 Oct 1997, Dean Gaudet wrote:
> 
> > 2.
> > 
> > The Port directive is a non-intuitive mess when applied to vhosts.  Consider:
> > 
> >     <VirtualHost 127.0.0.1>
> > 	Port 8080
> >     </VirtualHost>
> > 
> > That's a vhost on port 80, which will issue redirects indicating port 8080.
> > Solution?
> 
> I am more concerned about the case where someone makes a vhost on a
> different port (eg. main server port 80, vhost 8080) and forget the Port
> directive.  I'm afraid I'm not entirely clear on what the Port directive
> does that can't be figured out by what port something is really on.

The Port directive with virtual hosts is supposed to dictate only how
redirects are formed within that virtual host (the redirects requiring a
full-uri).  The Port directive globally has that function for the main
server, but it also dictates the default Listen if no other Listen is
specified.  It's the latter behaviour that I think causes confusion in a
vhost. 

We just need some way to generate the canonical servername:port for
generating redirects ... right now ServerName and Port define it.  It's
possible we could automate it somehow.

Dean



Re: more vhost thoughts

Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 5 Oct 1997, Dean Gaudet wrote:

> 2.
> 
> The Port directive is a non-intuitive mess when applied to vhosts.  Consider:
> 
>     <VirtualHost 127.0.0.1>
> 	Port 8080
>     </VirtualHost>
> 
> That's a vhost on port 80, which will issue redirects indicating port 8080.
> Solution?

I am more concerned about the case where someone makes a vhost on a
different port (eg. main server port 80, vhost 8080) and forget the Port
directive.  I'm afraid I'm not entirely clear on what the Port directive
does that can't be figured out by what port something is really on.