httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <>
Subject Re: Question and request for comments on patch
Date Fri, 22 Jul 2011 04:52:53 GMT
On 7/21/2011 3:32 AM, Igor Galić wrote:
> 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 <> 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,
>>   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

Attached is the final cut of the patch including doco and MMN bump as
you brought up. I plan to commit this on Monday, time permitting (and of
course in the absence of objections). I'll cobble something together
afterwards for a 2.2 backport.

Regarding the question, Igor, there was not much thought put into which
source tree I started hacking on - I wanted to get something together
before this weekend hit and already had this version configured/built.

Daniel Ruggeri

View raw message