On 4/17/23 1:07 PM, Yann Ylavic wrote:
> On Mon, Apr 17, 2023 at 9:08 AM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 4/16/23 12:20 PM, Graham Leggett via dev wrote:
>>> On 14 Apr 2023, at 17:18, Ruediger Pluem <rpl...@apache.org
>>> <mailto:rpl...@apache.org>> wrote:
>>>
>>>> Would that break configs like
>>>>
>>>> <Location /someplace>
>>>>
>>>> Alias /filesystemprefix/%{HTTP:X-example-header}
>>>>
>>>> </Location>
>>>>
>>>> where the expression evaluation determines the complete filesystem path
>>>> without adding the remainder of the URL?
>>>
>>> It would, which alas might mean we can't backport this, which isn’t great.
>>>
>>>> I admit that the above looks like a strange setup and is probably a bad
>>>> example, but the parameter to Alias could be an arbitrary
>>>> complex expression that evaluates to the final filesystem resource (like
>>>> AliasMatch). Wouldn't we need a kind of way to figure out
>>>> if the users wants the remainder of the URI added or not even if we do not
>>>> use a regular expression in the surrounding Location
>>>> block?
>>>
>>> LocationMatch is the correct way to do this - the config explicitly
>>> declares the exact URL to match, and the Alias gives the exact
>>> unambiguous mapping.
>>>
>>> Having a prefix in the “Alias /foo /bar” case and then arbitrarily not
>>> having a prefix in the “Alias /bar” case sent me on a huge
>>> wild goose chase - what made it worse was the client was a webdav client,
>>> so the behaviour just made no sense. I am seeing people
>>> asking why they’re getting a 405 and not getting answers, so I think this
>>> is tripping up other people too.
>>
>> I completely agree that Alias in a Location should behave as it does after
>> r1909137 and the behavior change is not a problem in
>> trunk, but I think due this behavior change it is not possible to backport
>> it as is.
>
> If we change the behaviour in trunk such that:
> 1. Alias /fake /real
> is the same as:
> 2. <Location /fake>
> Alias /real
> </Location>
> I'd suggest that we treat the /real part the same too (currently /real
> is a plain path in 1. and an expr in 2).
+1, but I guess this creates further backport problems one way or the other.
> It seems that:
> 3. <Directory /real>
> Alias /fake
> </Directory>
> could be a thing too (though /real would never be an expr here).
Is 3. really allowed today? I don't think so.
>
> Likewise "AliasMatch /fake /real" and LocationMatch + "AliasMatch
> /real" only should probably work the same, where /real could use
> captures from the LocationMatch (just like
> LocationMatch+ProxyPassMatch if I'm not mistaken).
I think AliasMatch inside LocationMatch does not work currently.
If we would want to make it work it could be kind of challenging to get the
captures
without executing the regex twice. Furthermore we need to be careful how we
intermix
capture replacements and expression execution. With the current code you could
use
Alias in LocationMatch and if you use named captures you can use them via
environment
variables in the expression execution which seems kind of safe.
>
> I also find the names in alias_dir_conf quite confusing, the "alias"
> corresponds to "real" in alias_entry used by alias_server_conf, while
> "alias_fake" corresponds to "alias". ISTM that alias_dir_conf should
> embed an alias_entry rather than duplicating all/most of its fields.
> Maybe we could even get rid of alias_server_conf actually and handle
> everything as perdir merging?
>
>> The question is if we find an approach to
>> make it backportable e.g. by adding some kind of 2.4.x only configuration
>> switch to get the behavior of r1909137.
>
> Maybe "AliasPerDirRelative on" (default: "off", context: "server
> config, virtual host, directory").
> And then we change the default to "on" in trunk.
I am not sure how we get out of this. All stuff sounds messy.
Probably we should create a clean solution for trunk and leave stuff in 2.4.x
as is.
For the case where the issue was discovered there is always a way to move the
Alias from the Location to virtual host context.
Probably we could add a warning log message in 2.4.x if the Alias in a Location
is just a plain string, that it might not behave
as the user expects.
Regards
Rüdiger
