Igor Galić wrote:

   One of the several things I'm uncertain about, though,
is how to distinguish the case of just wanting to override, say,
the Host header *after* the <VirtualHost> has been selected (perhaps
this is the default case, to work like RemoteIPHeader), from the
"extra" case of using the inserted new value before <VirtualHost>
selection, which is more in UseCanonicalHost's territory.

So, essentially, setting it as ServerAlias? But that doesn't make
it canonical, so UseCanonicalHost seems… inappropriate - or am I
misunderstanding your intent?

  I didn't mean to cause confusion; it was a poor choice of words.
I just meant that the actual code which performs the selection of the
applicable <VirtualHost> is "in the neighbourhood of" the code that
implements UseCanonicalHost (i.e., not in a module but in the core),
not that there was any particular sense in which this would be a
"canonical" choice of hostname.

  In short, I ended up patching core.c and vhost.c in order to
ensure that the value from X-Forwarded-Host was used everywhere
in place of the usual value for r->hostname, etc.  It's a hack
and should, I agree, move into a module like mod_remoteip --
along with some nice configs so one could say, "always use the
2nd-last hostname in X-Forwarded-Host, as that's from my trusted
front-end proxy" and such like.

  All I really meant in the previous note was that it would
be handy to have a further config flag which said either "use
this value *after* choosing <VirtualHost> the normal way" or
"use this value to choose your <VirtualHost>".  And that latter
action probably requires some workaround to get the module's
code to run ahead of the vhost selection in server/vhost.c.

Chris.

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

Reply via email to