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
