httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Galić <i.ga...@brainsware.org>
Subject RE: Question and request for comments on patch
Date Thu, 21 Jul 2011 08:32:38 GMT
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 <DRuggeri@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
Mime
View raw message