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).
It seems that:
3. <Directory /real>
Alias /fake
</Directory>
could be a thing too (though /real would never be an expr here).
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 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.
Regards;
Yann.
