httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: ssl-std.conf
Date Wed, 07 Nov 2001 23:49:26 GMT
On Thu, Nov 08, 2001 at 12:30:50AM +0100, Martin Kraemer wrote:
> > The ServerName directive syntax changed with 2.0
> > There is no Port directive anymore and I think that is what is causing the
> > problem, it needs to be explictly declared on the servername if the port is
> > other than 80
> But that makes no sense! I can have dozens of "Listen" directives (without
> dozens of virtual hosts!), or a <Virtualhost*> block.
> So what would you write on the ServerName then?
>   "ServerName*" ?

Having only one cannonical name and multiple Listen directives has
always been a sore spot, with or without the Port directive. I agree
with what you're saying, but I think that is a separate issue that
needs to be solved with vhost configuration.

> It should append the actual port on which the request appeared, and no
> halfway guessed default from a /etc/services list. That was the whole idea
> behind removing the "Port" directive which could lie about the "canonical"
> port, wasn't it? (Or was the idea that "ServerName"
> would do the same as "Port 8443" in 1.3?)

I think it would be incorrect to simply append the port on which the
request appeared. Think of hosts behind port-redirecting firewalls.
The ServerName host:port may not correspond with the Listen port, but
it better construct redirects with the host:port given in the ServerName

> At least, the heuristics should be fixed. It is plain wrong to redirect
> a request coming in via ssl on port 8443, to a location "https://hostname:80/".

Perhaps, but I think the committed fix is correct for this case. This
particular vhost should have a cannonical name of,
and was simply misconfigured.

> * In the absense of a port on the ServerName, the port should be taken from
>   the actual request, and not incorrectly guessed/derived from the protocol.
> * when a port is present on the ServerName, then the implementation can
>   use that in place of the actual port.

I disagree here. If defaulting to port 80 is causing problems (especially
since httpd is leaning toward other protocols now) then we need to force
the admin to put a port on the ServerName directive.


View raw message