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. 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.
Regards
Rüdiger
