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.

Reply via email to