I think you're missing an MMN bump, regarding backporting - or API in general, the wrapper is the right way to go. Also: Why not patch against trunk?
i Daniel Ruggeri <drugg...@primary.net> wrote: >All; > I am attaching a patch that will allow for a comma separated list of >directives permissable for override. I am doing this because the >existing AllowOverride list of override-able directives sometimes has >too many things, sometimes allows more than is documented and it also >forces third party modules into one of the four predefined lists. With >this patch, an AllowOverrideList directive is added for the server admin >to specify individual directives for override. No other functionality >changes. FWIW, In my particular use case, I would like to grant a >content admin the ability to implement a server-side redirect in >.htacess, but would NOT like to grant them the ability to stand up a >proxy via "RewriteRule / http://someOtherLocation/ [P]" (which is what >would happen if FileInfo was set in AllowOverride). Note how Redirect >and friends are not documented as directives in core.html#allowoverride >for FileInfo... another patch, another day :) . > > > With that in mind, I'd like to request comments on the idea and the >implementation supplied. I can see that there could be efficiency gained >without having to "tolower" each directive before comparison in >invoke_cmd, but I could not find a way outside of server/config.c >(server/core.c constructs the list I am using) to look up a directive's >normal case like ReDiREcT becomes "Redirect" before the call to >invoke_cmd as a result of ml = apr_hash_get(ap_config_hash, dir, >APR_HASH_KEY_STRING);. > > > The second thing I'd like to bring up is that I see a lot of use in >backporting this, but I have made a change that I think would be >considered an API change (added param to ap_parse_htaccess in >include/http_config.h). Since I know this is not allowed, would it be >acceptable to rename the new ap_parse_htaccess function and implement a >wrapper as ap_parse_htaccess? I would foresee that such a wrapper would >issue a deprecation warning when called, but will call ap_parse_htaccess >with a NULL in place of the (new) override_list. > >cheers! >-- >-- >Daniel Ruggeri
