On Mon, Jun 22, 2015 at 12:26 PM, Yann Ylavic <[email protected]> wrote: > On Mon, Jun 22, 2015 at 10:50 AM, Plüm, Rüdiger, Vodafone Group >> @Yann: Wouldn't it make sense to check for cmd->path as well before we do >> the expression parsing stuff to ensure we are really in a <Location...> >> section? > > Yes, that's where I wanted to go for a final version of the patch, > since the comment (above that code) states: "we use the expression > syntax assuming a path from the location".
The attached patch enables expressions for <Location> context only a redirect status. I'll try to add tests in framework when I have little time... > OTOH, I don't see why it would be limited to a <Location> context... > But try_redirect() uses per_dir_config only, so it's probably better > to not change this for now, and handle module_config in a follow up > (once 2.4.16 is out! :) > > AIUI though, we now accept the URL to be (possibly) an expression, but > I don't understand why we need these new alias_dir_conf entries to > handle that, can't we simply use a new expr field in the alias_entry > (maybe with some heuristic to use a plain string if no real expression > is used, for performances reasons if that matters), and thus preserve > the 2.4.12 logic? > > Also, I think we should handle any non-redirect (custom) statuses like > we do for HTTP_GONE (no third/second URL argument required nor > relevent, depending on vhost/location context), and mention it in the > doc :) > > So finally this makes me wonder if we'd better not revert the change > for now (at least the Redirect* part since Alias* changes look good), > and think more about the possible Redirect* uses. I can't find a related bugzilla for the feature (not sold already :), so either way for me, revert or something like the attached... > > Regards, > Yann.
httpd-2.4.x-mod_alias-redirect_expr.patch
Description: application/download
