Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: error (nike.apache.org: local policy)
Message-ID: <51DECDE0.1070604@pearsoncmg.com>
Date: Thu, 11 Jul 2013 08:23:12 -0700
From: Chris Darroch <chrisd@pearsoncmg.com>
Organization: Pearson CMG/PLT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.24) Gecko/20100319 SeaMonkey/1.1.19
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: UseListenScheme proposal
References: <51DE1482.6060503@pearsoncmg.com>
 <8201F7B6-F44D-443E-BC2E-A17273518D9F@webthing.com>
In-Reply-To: <8201F7B6-F44D-443E-BC2E-A17273518D9F@webthing.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Nick:

>> The idea is to introduce a non-default "UseListenScheme On" setting
>> which uses the scheme from the Listen directive when constructing
>> self-referencing URLs:
> 
> Can you clarify for the lazy among us how this might interact with
> existing configuration options for self-referencing URLs?  I'm thinking
> mainly "UseCanonicalName" and "Header Edit", though there's also
> the ProxyPass* family, hairy Rewrite hacks, and other bits&pieces.
> 
> (a) What does your patch enable over and above what we have?

   It's pretty basic -- the current logic in ap_construct_url()
when determining the scheme is from http_scheme() in modules/http,
namely, use the scheme from ServerName, if any, otherwise "http".

   This patch adds a preceding check: first look for a scheme in
the corresponding Listen directive, then for a scheme in ServerName,
and finally fall back to "http".

   The ap_construct_url() code is used, so far as I know, in just a
handful of key places where self-referencing URLs are created for
Location headers: handling Redirects and ProxyPassReverse header munging,
adding trailing / chars in mod_dir, generating Location headers in
mod_dav, and a couple of other spots.

   The UseListenScheme directive plays alongside the other two
directives UseCanonicalName and UseCanonicalPhysicalPort in telling
ap_construct_url() what to do.  I didn't see a clean way to add
to their configuration options something involving the scheme; it
seemed cleaner to add a separate directive so we have one each to
specify how scheme, name, and port are determined in ap_construct_url().


> (b) How much duplication of functionality does it introduce?

   None, so far as I can tell ...

> (c) Is there a potential opportunity to deprecate some of our uglier
> historic hacks and clean up duplication?

   I didn't see a way to do this and retain backwards-compatibility
for configuration files around ServerName, etc.  And I was really
looking for something which would leverage the existing configs in
an example like the one I supplied, where Listen "should" be telling
the server that traffic on a specific port needs the https:// scheme.

   And to be honest, I need to backport this to 2.2.x for our internal
purposes, so I wasn't looking for a big trunk/2.6/3.0 config cleanup
opportunity (and I do not want to open that can of worms here! :-)
I'm sure 3.0 could benefit from collapsing the Use* directives down,
and possibly reworking how ServerName, ServerAlias, Listen, etc.
all play together.  For another day ...

Chris.

-- 
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820  6715 F54F E648 0883 35A9