You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by bu...@apache.org on 2020/12/17 05:30:16 UTC
[Bug 64997] New: documenation about implictily added ServerAliases
from VirtualHost directive names seem incomplete
https://bz.apache.org/bugzilla/show_bug.cgi?id=64997
Bug ID: 64997
Summary: documenation about implictily added ServerAliases from
VirtualHost directive names seem incomplete
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Documentation
Assignee: docs@httpd.apache.org
Reporter: calestyo@scientia.net
Target Milestone: ---
Hi.
vhosts/name-based.html says:
> The complete list of names in the VirtualHost directive are treated just like a (non wildcard) ServerAlias.
and
vhosts/details.html says:
> The complete list of names in the VirtualHost directive are treated just like a (non wildcard) ServerAlias (but are not overridden by any ServerAlias statement).
1) First, the wording here is a bit strange, especially the "(non wildcard)"...
no sure what that really tries to tell here, as a domainname in VirtualHost
couldn't contain a wildcard anyway?
If it means that *:* or *:80 doesn't implicitly add "*" as a ServerAlias, that
should be made more clear.
But from my testing it rather means that any name where the port is "*", like
"example.com:*" wouldn't get added.
2) Second and more important, the described behaviour seems only half the
truth. From my live tests it seems that a (Server)Alias is only added for
accesses made on the port that is given together with the domainname in
<VirtualHost>.
Consider the following example in that order:
(with foo.example.com pointing to 10.10.10.10 in DNS)
VirtualHost 10.10.10.10:80 10.10.10.10:8080>
ServerName default-vhost.example.com
...
</VirtualHost>
VirtualHost 10.10.10.10:80 10.10.10.10:8080 foo.example.com:80>
ServerName other-vhost.example.com
...
</VirtualHost>
An access to foo.example.com:80 will end up on other-vhost, but(!) an access to
foo.example.com:8080 ends up on default-vhost ... which is unexpected as
other-vhost also listens on 10.10.10.10:8080 and allegedly the domainname from
it's VirtualHost would have been added as ServerAlias.
But it's apparently not generally added, *but only* for the indicated port.
Cheers,
Chris
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
[Bug 64997] documenation about implictily added ServerAliases from
VirtualHost directive names seem incomplete
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64997
Christoph Anton Mitterer <ca...@scientia.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from Christoph Anton Mitterer <ca...@scientia.net> ---
Hmm yeah, that seems ok-ish, at least for (2).
I'd perhaps change:
> and the hostname:port
> combination is also checked prior to ServerName and ServerAlias
> checks for name-based virtual host
> resolution.
to
> and the hostname:port combination (if neither hostname nor port is the wildcard)
> is also checked (prior to names in ServerName and ServerAlias)
> for name-based virtual host resolution.
It does however not deal with (1) which I'd have done above with "(if neither
hostname nor port is the wildcard)"
And generally, hostname is also a bit ambiguous, since these names are not
necessarily canonical hostnames (actually that's what vhosting is all about)
but rather domain names.
Apart from that, maybe it's actually the behaviour that should be changed for
(2):
AFAIU, a vhost has two properties here:
a) the address/port combinations it would apply to
b) the domainnames matched against the HTTP Host header.
(a) is set with <VirtualHost>, (b) with ServerName/ServerAlias.
It's a bit strange that for the names set via ServerName/ServerAlias any
addr/port matched by the vhost fit, but not for the - conceptually identical -
names set via <VirtualHost>.
Cheers,
Chris.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
[Bug 64997] documenation about implictily added ServerAliases from
VirtualHost directive names seem incomplete
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64997
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Eric Covener <co...@gmail.com> ---
I took a crack at this in http://svn.apache.org/viewvc?rev=1884555&view=rev
should be published on
https://httpd.apache.org/docs/trunk/vhosts/name-based.html soon
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
[Bug 64997] documenation about implictily added ServerAliases from
VirtualHost directive names seem incomplete
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64997
--- Comment #3 from Christoph Anton Mitterer <ca...@scientia.net> ---
Oh and all that is now in vhosts/name-based.html, but missing in
vhosts/name-based.html.
It's a bit unfortunate that the whole system (which is actually not that
extremely difficult) is scattered over so many places.
In fact, conceptually it seems that httpd doesn't differ between IP-based and
name-based at all.
It's always just:
1) first take any vhosts whose addr:port match literally (i.e. no wildcard)
2) if none, take also those with wildcards)
3) if there is a HTTP Host Header, match that in the remaining vhosts and fall
back to the first one if no-one matches or there is none.
4) if there was matching no vhost at all, give it to the main server
Apart from some details, like where to get default ServerName/Alias from,... or
the thing with the implicitly added ServerAlias from <VirtualHost>,... that's
it, isn't it?
In the documentation there seem currently a lot of text writing "around" these
simple rules.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
[Bug 64997] documenation about implictily added ServerAliases from
VirtualHost directive names seem incomplete
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64997
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Eric Covener <co...@gmail.com> ---
(In reply to Christoph Anton Mitterer from comment #2)
> Hmm yeah, that seems ok-ish, at least for (2).
>
> I'd perhaps change:
> > and the hostname:port
> > combination is also checked prior to ServerName and ServerAlias
> > checks for name-based virtual host
> > resolution.
>
This sentence begins with "when a hostname is specified" so I prefer to not
make it any longer / more complicated.
-/-
I don't think many readers will be confused by hostname vs. domain name. I
think "hostname" is actually more accessible to a casual user.
-/-
> Apart from that, maybe it's actually the behaviour that should be changed > for (2):
I think there would have to be a really compelling reason to change behavior in
this area. You may want to make a standalone argument in a standalone issue
that considers externals and migration as opposed to some ideal behavior.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org