On Mon, Jun 22, 2015 at 10:50 AM, Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com> wrote: > > >> -----Original Message----- >> From: Eric Covener [mailto:cove...@gmail.com] >> Sent: Montag, 22. Juni 2015 01:08 >> To: Apache HTTP Server Development List >> Subject: Re: [VOTE] Release Apache httpd 2.4.15 as GA >> >> On Sun, Jun 21, 2015 at 5:24 PM, William A Rowe Jr <wr...@rowe-clan.net> >> wrote: >> > As this is not a regression from 2.4.13 or 2.4.14 candidates, it seems >> to me >> > we should ship. >> >> I am -1 for 2.4.15 with the regression. The other candidates being >> broken doesn't mitigate it much for me. > > +1 to Eric's comment and > -1 from me as well on the release. Looks like we are a little bit out of luck > with 2.4.x releases recently :-). > My proposal is to leave the vote open at most for 24 hours to see if anything > more comes up and then roll 2.4.16 > with the patch from Yann applied. > @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? > > So something like: > > @@ -270,7 +273,7 @@ > * if we understand the first arg but have no second arg, we are dealing > * with a status like "GONE". > */ > - if (grokarg1 && arg2 && !arg3 && HTTP_GONE != status) { > + if (grokarg1 > 0 && arg2 && !arg3 && cmd->path && HTTP_GONE != status) { > const char *expr_err = NULL; > > dirconf->redirect =
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". 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. Regards, Yann.
