httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: r->hostname vs. s->server->server_hostname
Date Fri, 02 Jan 1998 00:25:59 GMT
There's like a half-dozen PRs mentioning the related issue of how the port
number is chosen for generating these "canonical" URLs.  My opinion on
this topic is that web servers have a single canonical name, and catering
to "http://www/" is not worth any effort in core code.  I'd rather just
advocate a mod_rewrite rule that sends a redirect to correct broken URLs.
Apache right now dictates that a server has a single canonical name. 

That doesn't mean I'd veto a change that gets rid of the concept of a
canonical name, and generates URLs using (r->hostname ? r->hostname :
r->server->server_hostname) and ntohs(r->connection->local_addr.sin_port).

If we go that way, the Port directive should be disallowed inside vhosts,
and Port should be documented as only there for legacy compatibility with
NCSA, in the main server only. 

Some of this is related to Martin's URL parsing patches that are in
progress still. 

Dean

On Thu, 1 Jan 1998, Marc Slemko wrote:

> background: say you want to use mod_rewrite to implement large numbers of
> pseudo vhosts (without using real vhosts with their overhead), eg. one for
> each user. It appears like this _almost_ works.  You need to make a custom
> log using {Host}i to get the server name logged right, but that isn't a
> big deal. 
> 
> The problem comes with when Apache has to generate the servername.  This
> happens in several places, but one most visable externally is in the
> creation of redirects; they get redirected to the ServerName name instead
> of the pseudo-vhost name.
> 
> Why not use r->hostname instead of s->server_hostname for generating the
> redirect URL (and possibly other things... but you have to be very careful
> there...) if it is set?  This has the added advantages of eliminating all
> the double auth problems when someone gets a redirect from http://site/foo
> to http://site.domain.com/foo/ in addition to fixing the redirect problem
> here.
> 
> The problem is that construct_url doesn't take the request_rec but only
> the server_rec.  A new function could be added easily enough that took the
> request_rec instead and did this, since all construct_url does is:
> 
> API_EXPORT(char *) construct_url(pool *p, const char *uri, const
> server_rec *s)
> {
>     return pstrcat(p, "http://",
>                    construct_server(p, s->server_hostname, s->port),
>                    uri, NULL);
> }
> 
> The disadvantage of this idea is that it doesn't discourage URL-variance,
> however it isn't encouraging it; just lessening the effect of it changing
> in midstream.  This would eliminate a lot of user problems since most
> clients send the Host: header.
> 
> Comments?
> 
> 


Mime
View raw message