You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <ma...@hp.com> on 2001/11/07 23:13:35 UTC
ssl-std.conf
Hi,
Is anybody seeing the warning message "You configured HTTPS(443) on
the standard HTTP(80) port!" in the logs/ssl_engine_log file ?.. The
following patch seems to fix the problem.. Any comments - is this fix okay
?..
Thx
-Madhu
Index: ssl-std.conf
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/conf/ssl-std.conf,v
retrieving revision 1.6
diff -u -r1.6 ssl-std.conf
--- ssl-std.conf 2001/11/01 05:12:46 1.6
+++ ssl-std.conf 2001/11/07 21:30:45
@@ -100,7 +100,7 @@
# General setup for the virtual host
DocumentRoot "@@ServerRoot@@/htdocs"
-ServerName new.host.name
+ServerName new.host.name:443
ServerAdmin you@your.address
ErrorLog logs/error_log
TransferLog logs/access_log
Re: [PATCH] Re: ssl-std.conf
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Thu, Nov 08, 2001 at 11:18:14AM +0100, Kraemer, Martin wrote:
>
> Comments?
committed.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
[PATCH] Re: ssl-std.conf
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Wed, Nov 07, 2001 at 05:58:57PM -0800, Roy T. Fielding wrote:
> This sounds like a pointless discussion. Let's just fix the problem and
> move on. The problem is that ServerName without a port is not supposed to be
> equivalent to a ServerName with :80 stuck on the end, but that is how it is
> currently implemented.
Thanks, Roy.
Yes, there are two philosophies behind the long discussion.
1) Reduce the server's multiple identities to well-defined
hostname:port pairs, each associated with a <VirtualHost>+ServerName
combo.
-vs.-
2) Reflect the fact that the configuration allows for manyfold combinations
of IP addresses, ports, and host names, with or without an enforced
"canonical name" (==identity) philosophy.
While I see the advantage of 1), I would like to avoid users to fall
into the https://...:80/ trap. The constant 80 must be eliminated;
Apache should "do the right thing" even without the
"ServerName name:port" workaround.
The actual problem is this:
1621 static const char *server_hostname_port(cmd_parms *cmd, void *dummy, const !
1622 {
1623 const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE|NOT_IN_!
1624 const char *portstr;
1625 int port;
1626
1627 if (err != NULL) {
1628 return err;
1629 }
1630 portstr = ap_strchr_c(arg, ':');
1631 if (portstr) {
1632 cmd->server->server_hostname = apr_pstrndup(cmd->pool, arg,
1633 portstr - arg);
1634 portstr++;
1635 port = atoi(portstr);
1636 }
1637 else {
1638 cmd->server->server_hostname = apr_pstrdup(cmd->pool, arg);
=>1639 port = 80;
1640 }
1641 if (port <= 0 || port >= 65536) { /* 65536 == 1<<16 */
1642 return apr_pstrcat(cmd->temp_pool, "The port number \"", arg,
1643 "\" is outside the appropriate range "
1644 "(i.e., 1..65535).", NULL);
1645 }
1646 cmd->server->port = port;
1647 return NULL;
1648 }
In 1.3, we left the port at 0 and used code like
port = r->server->port ? r->server->port : ap_default_port(r);
at run time to determine the actual port for _the_request_. Now we try
to do it _during_configuration_.
With the appended patch, the following changes were made:
@) If the "ServerName hostname:port" syntax is used, it *always* has
precedence, with UseCanonicalName set to On, Off or DNS.
This is current behavior, and was not changed.
But when "ServerName hostname" only is used, then:
a) the port -if unset- is set to 0 (not 80) at configuration time.
It is checked at run time where appropriate.
b) The actual port is returned by ap_get_server_port() if
UseCanonicalName is Off or DNS. There was a bogus test for
r->hostname which I eliminated too. For UseCanonicalName On,
the ap_default_port(r) is used instead, which is 443 for https:
and 80 for http:.
This fixes the problem I and others observed, and I tested it
thoroughly with varying ServerName/UseCanonical/Host: combinations.
The change in ssl-std.conf can remain there, but is actually redundant.
Because it is more difficulty to maintain (has to be patched during
make install), I suggest removing the :443 again because Apache now
"does the right thing".
Comments?
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: ssl-std.conf
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > Agreed. The point of putting the port on the ServerName line was to just
> > replace the port directive. It shouldn't have impacted redirects.
>
> Huh?? The whole point of the Port and ServerName directives was/is to
> configure the target of self-referencing redirects.
This sounds like a pointless discussion. Let's just fix the problem and
move on. The problem is that ServerName without a port is not supposed to be
equivalent to a ServerName with :80 stuck on the end, but that is how it is
currently implemented.
Of course, fixing it is going to be harder than just identifying the problem.
....Roy
Re: ssl-std.conf
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Wed, Nov 07, 2001 at 04:58:34PM -0800, Ryan Bloom wrote:
>
> Agreed. The point of putting the port on the ServerName line was to just
> replace the port directive. It shouldn't have impacted redirects.
Now that I found the fix, I agree with you (and with the implementation):
It is true (and makes sense) that
ServerName hostname # in Apache-2.0
is the same as
# no Port directive, and
ServerName hostname # in Apache-1.3
And
ServerName hostname:port # in Apache-2.0
is the same as
Port port
ServerName hostname # in Apache-1.3
The only buglet was the fact that port 80 was implied during configuration,
while it would have been more correct to leave that decision open until
run time, by using port=0.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: ssl-std.conf
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 7 Nov 2001, Ryan Bloom wrote:
> > 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/".
>
> Agreed. The point of putting the port on the ServerName line was to just
> replace the port directive. It shouldn't have impacted redirects.
Huh?? The whole point of the Port and ServerName directives was/is to
configure the target of self-referencing redirects.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: ssl-std.conf
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 07 November 2001 03:30 pm, Martin Kraemer wrote:
> 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 host.name.dom:8443"
> would do the same as "Port 8443" in 1.3?)
>
> 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/".
Agreed. The point of putting the port on the ServerName line was to just
replace the port directive. It shouldn't have impacted redirects.
Ryan
>
> So, IMHO,
>
> * 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.
>
> Martin
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: ssl-std.conf
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Wed, Nov 07, 2001 at 07:24:38PM -0500, Cliff Woolley wrote:
>
> Port and ServerName logically go together, might as well
> combine them into one directive and cut through all these problems.
Good resume' . Agreeing completely. (I fell into that trap myself in
the early days).
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: ssl-std.conf
Posted by Daniel Lopez <da...@rawbyte.com>.
Ok, if there was actually a problem with people getting confused with Port
and Listen, then that may be the reason I was missing for the Port change.
People coming from Apache 1.3 are going to still get confused a bit though
(Martin and I did, at least :)
> People with existing working configurations were never the problem. It's
> people trying to get it set up right in the first place that got confused
> by it. We got probably dozens of bug reports (and even patches!) about
> this, all because of people misunderstanding the difference between Listen
> and Port. Port and ServerName logically go together, might as well
> combine them into one directive and cut through all these problems.
Re: ssl-std.conf
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Daniel Lopez" <da...@rawbyte.com>
Sent: Wednesday, November 07, 2001 6:20 PM
>
> I understand how the mechanism works, what confuses me is removing the
> Port directive and adding it in the ServerName. Many Apache 1.3 users, when
> upgrading to Apache 2.0 are going to be looking for the Port directive, take
> a few minutes to figure out what is going wrong, read the docs and use
> ServerName instead.
I'd suggest we make _CERTAIN_ that the word 'Port' still exists, under the
ServerName directive explanations in ssl-std.conf and httpd-std.conf. At
least the s/Port/ gives them some result.
> No big deal, but for the same reason, why change the syntax?
> (just following the golden rule of engineering "if it works, don't mess with it" :)
Again, this comes up weekly... I've even seen engineers bitten by the port
vs. listen so it wasn't clear [enough] before. Of course, that was in the
bad old days of BindAddress/Listen/Port ;)
Re: ssl-std.conf
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 7 Nov 2001, Daniel Lopez wrote:
> I understand how the mechanism works, what confuses me is removing the
> Port directive and adding it in the ServerName. Many Apache 1.3 users, when
> upgrading to Apache 2.0 are going to be looking for the Port directive, take
> a few minutes to figure out what is going wrong, read the docs and use
> ServerName instead. No big deal, but for the same reason, why change the
> syntax?
> (just following the golden rule of engineering "if it works, don't
> mess with it" :)
People with existing working configurations were never the problem. It's
people trying to get it set up right in the first place that got confused
by it. We got probably dozens of bug reports (and even patches!) about
this, all because of people misunderstanding the difference between Listen
and Port. Port and ServerName logically go together, might as well
combine them into one directive and cut through all these problems.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: ssl-std.conf
Posted by Daniel Lopez <da...@rawbyte.com>.
I understand how the mechanism works, what confuses me is removing the
Port directive and adding it in the ServerName. Many Apache 1.3 users, when
upgrading to Apache 2.0 are going to be looking for the Port directive, take
a few minutes to figure out what is going wrong, read the docs and use
ServerName instead. No big deal, but for the same reason, why change the
syntax?
(just following the golden rule of engineering "if it works, don't mess with it" :)
> > I agree with you. I never really understood the need to remove the port
> > directive, I never heard anybody complain about it. It just confuses people.
>
> No... they are confused [search bugs, and the lists, and the newsgroups.]
>
> A vhost (or the default server) has one and only one identity [servername]
> but potentially many aliases [serveralias]. A vhost has one and only one
> port identity as well [was Port], which has simply been combined with it's
> one and only one identity.
>
> Not really confusing, when you remember that ServerName/ServerAlias are only
> identities, and Listen is the actual port configuration.
>
> Bill
>
Re: ssl-std.conf
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Daniel Lopez" <da...@rawbyte.com>
Sent: Wednesday, November 07, 2001 5:40 PM
> > But that makes no sense! I can have dozens of "Listen" directives (without
> > dozens of virtual hosts!), or a <Virtualhost ip.ad.d.r:*> block.
> > So what would you write on the ServerName then?
> > "ServerName host.name.dom:*" ?
>
> I agree with you. I never really understood the need to remove the port
> directive, I never heard anybody complain about it. It just confuses people.
No... they are confused [search bugs, and the lists, and the newsgroups.]
A vhost (or the default server) has one and only one identity [servername]
but potentially many aliases [serveralias]. A vhost has one and only one
port identity as well [was Port], which has simply been combined with it's
one and only one identity.
Not really confusing, when you remember that ServerName/ServerAlias are only
identities, and Listen is the actual port configuration.
Bill
Re: ssl-std.conf
Posted by Daniel Lopez <da...@rawbyte.com>.
> But that makes no sense! I can have dozens of "Listen" directives (without
> dozens of virtual hosts!), or a <Virtualhost ip.ad.d.r:*> block.
> So what would you write on the ServerName then?
> "ServerName host.name.dom:*" ?
I agree with you. I never really understood the need to remove the port
directive, I never heard anybody complain about it. It just confuses people.
Daniel
Re: ssl-std.conf
Posted by Aaron Bannert <aa...@clove.org>.
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 ip.ad.d.r:*> block.
> So what would you write on the ServerName then?
> "ServerName host.name.dom:*" ?
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 host.name.dom:8443"
> 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
directive.
> 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 host.example.com:443,
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.
-aaron
Re: ssl-std.conf
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Thu, Nov 08, 2001 at 12:30:50AM +0100, Martin Kraemer wrote:
> On Wed, Nov 07, 2001 at 03:17:36PM -0800, Daniel Lopez 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 ip.ad.d.r:*> block.
> So what would you write on the ServerName then?
> "ServerName host.name.dom:*" ?
ServerName without a port simply means redirect on the port in server_rec.
This is just a side-effect of the Port directive being removed -- it would
be just as broken to require Port be defined wherever ssl is used.
> > > IMHO the real fix is to repair the place where the ":80" is appended
>
> 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 host.name.dom:8443"
> would do the same as "Port 8443" in 1.3?)
The server must store sufficient information in the server_rec in order
for the request to generate a default redirect. That means both the scheme
name and the port number if the port is not the default for that scheme.
In other words, just add two more string pointers to server_rec and have
the server initialize them at start-up, and then change our redirect
generating code to use those values.
....Roy
Re: ssl-std.conf
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Wed, Nov 07, 2001 at 03:17:36PM -0800, Daniel Lopez 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 ip.ad.d.r:*> block.
So what would you write on the ServerName then?
"ServerName host.name.dom:*" ?
> > IMHO the real fix is to repair the place where the ":80" is appended
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 host.name.dom:8443"
would do the same as "Port 8443" in 1.3?)
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/".
So, IMHO,
* 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.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: ssl-std.conf
Posted by Daniel Lopez <da...@rawbyte.com>.
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
> > > Is anybody seeing the warning message "You configured HTTPS(443) on
> > > the standard HTTP(80) port!" in the logs/ssl_engine_log file ?.. The
> > > following patch seems to fix the problem.. Any comments - is this fix okay
> > > ?..
> >
> > Looks fine to me. Committed.
>
> Is that really the right fix? In 1.3, at least, that would lead to the
> situation where the server name and the port will be printed twice,
> like:
> Apache/1.3.22 Server at my.host.dom:8443 Port 8443
>
> IMHO the real fix is to repair the place where the ":80" is appended
> (where from? there is no "80" in my config! probably default_port_for_*())
> when I try:
>
> % openssl s_client -connect deejai2.mch.fsc.net:8443
> ....
> HEAD /manual HTTP/1.0
>
> and get this response:
> HTTP/1.1 301 Moved Permanently
> Date: Wed, 07 Nov 2001 23:08:06 GMT
> Server: Apache/2.0.28-dev (Unix) DAV/2 mod_ssl/3.0a0 OpenSSL/0.9.6a
> Location: https://deejai2.mch.fsc.net:80/manual/
> ------------^Ok^^---------------------^bogus^
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> Just my $.02,
> Martin
> --
> <Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
> Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: ssl-std.conf
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Wed, Nov 07, 2001 at 05:28:34PM -0500, Cliff Woolley wrote:
> On Wed, 7 Nov 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
>
> > Is anybody seeing the warning message "You configured HTTPS(443) on
> > the standard HTTP(80) port!" in the logs/ssl_engine_log file ?.. The
> > following patch seems to fix the problem.. Any comments - is this fix okay
> > ?..
>
> Looks fine to me. Committed.
Is that really the right fix? In 1.3, at least, that would lead to the
situation where the server name and the port will be printed twice,
like:
Apache/1.3.22 Server at my.host.dom:8443 Port 8443
IMHO the real fix is to repair the place where the ":80" is appended
(where from? there is no "80" in my config! probably default_port_for_*())
when I try:
% openssl s_client -connect deejai2.mch.fsc.net:8443
....
HEAD /manual HTTP/1.0
and get this response:
HTTP/1.1 301 Moved Permanently
Date: Wed, 07 Nov 2001 23:08:06 GMT
Server: Apache/2.0.28-dev (Unix) DAV/2 mod_ssl/3.0a0 OpenSSL/0.9.6a
Location: https://deejai2.mch.fsc.net:80/manual/
------------^Ok^^---------------------^bogus^
Connection: close
Content-Type: text/html; charset=iso-8859-1
Just my $.02,
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: ssl-std.conf
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 7 Nov 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> Is anybody seeing the warning message "You configured HTTPS(443) on
> the standard HTTP(80) port!" in the logs/ssl_engine_log file ?.. The
> following patch seems to fix the problem.. Any comments - is this fix okay
> ?..
Looks fine to me. Committed.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA