[PATCH] Re: ssl-std.conf

[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: [PATCH] Re: ssl-std.conf

[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