https://bz.apache.org/bugzilla/show_bug.cgi?id=57337
Alex Smith <alex....@madalex.me.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alex....@madalex.me.uk
--- Comment #2 from Alex Smith <alex....@madalex.me.uk> ---
Created attachment 36018
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36018&action=edit
Propsed patch (first attempt, against 2.4.33)
I also ran into this issue, when attempting to implement automatic upgrading of
HTTP requests to the equivalent HTTPS requests only for browsers likely to
support SNI. Analysis and details of the attached proposed patch below:
Analysis
--------
The root cause is that the merging of conditional sections (<If> and friends)
that are enabled for the request only occurs in the `per-directory'
configuration tree, rooted within the applicable vhost. Therefore any
conditional server / vhost wide configuration only gets picked up at the point
that a mapping to the filesystem is established, which is rather late.
What is happening in the reported scenario is as follows:
Configuration parsing:
* The <If> is treated like a top-level <Directory> section.
* mod_alias stores server / vhost wide aliases and redirects in the `server'
configuration tree; there are none in the reported example, due to the handling
of the <If> section.
* mod_alias stores the aliases and redirects within each directory-like
section, which includes the <If>, in the `per-directory' configuration for that
section.
Request processing:
* The `per-directory' configuration for the request starts as that for the
top-level for the vhost.
* Conditional (<If) section merging into that `per-directory' configuration is
performed.
* In the `translate name' hook, mod_alias looks for applicable aliases and
redirects in its `server' configuration. There aren't any.
* In the `type checker' hook, mod_negotiation finds the possible variants and
performs a sub-request for each one.
* During the sub-request for the first possible variant, the full
`per-directory' configuration is constructed by merging everything relevant for
that file.
* The mod_alias `fixups' hook then gets invoked, as part of the sub-request,
and looks for applicable aliases and redirects in its part of the merged
`per-directory' configuration for the sub-request, finding the conditional
redirect that was merged from the <If> and applying it.
* mod_negotiation bails as described due to the sub-request not returning OK,
i.e. because it returns the redirect status.
That mod_negotiation bails when the sub-request indicates a redirection is
reasonable, although a clearer error would be useful in this case; consider a
configuration with a redirect configured for only one of the possible variants.
The long-term fix would be to extend the conditional section processing to the
`server' configuration processing, creating `server' <If> sections (instead of
`per-directory' <If> sections) when they appear in global / vhost scope, within
<Location> sections or as immediate children of other `server' <If> sections.
When any are found a request-local copy of the server configuration would have
to be taken and those that are enabled merged in. This would also allow e.g.
conditional <Location> sections, but would clearly be a large piece of work and
would require numerous module interface changes.
Proposed Patch
--------------
The attached patch is a shorter-term fix for just this issue. It makes
mod_alias look in the merged `per-directory' configuration in the `translate
name' hook if it didn't find a match in the `server' configuration, even though
it is only the top-level directory configuration at that stage. Hence, when the
<If> is enabled and it has been merged in, the conditional redirect is picked
up early enough.
The patch has been taken against 2.4.33 and needs `patch -p1' in the root
directory. It applies cleanly to trunk as of now, but I've only had a chance to
test it on 2.4.33.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
