Bug 65073 - <LocationMatch> claims consecutive slashes were not matched, while MergeSlashes claims the opposite
Summary: <LocationMatch> claims consecutive slashes were not matched, while MergeSlash...
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Documentation (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 major (vote)
Target Milestone: ---
Assignee: HTTP Server Documentation List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-12 05:32 UTC by Christoph Anton Mitterer
Modified: 2021-04-13 00:34 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2021-01-12 05:32:42 UTC
Hey.

in mod/core.html...

- <Location> AND <LocationMatch> BOTH claim in their paragraphs "Note about / (slash)", that consecutive slashes were NOT merged in the regex-version AND the non-regex-version for proxy requests.

to the contrary:
- MergeSlashes (which defaults to ON), claims that multiple slashes would be merged, at least also in the regex-versions (specifically mentioning <LocationMatch> ... and ignoring proxy requests).


What is it now?


Marking this issue as majoir, since the wrong documentation can IMO easily trick people into setting up wrong access controls.


Cheers,
Chris.
Comment 1 Christoph Anton Mitterer 2021-04-13 00:26:28 UTC
Some testing reveals that apparently the documentation of Location/LocationMatch is wrong, and slashes are indeed merged as claimed by MergeSlashes.

1) with: MergeSlashes On
<LocationMatch "^/xx//yy$">
request to "/xx/yy"  => no match
request to "/xx//yy" => no match

<LocationMatch "^/xx/yy$">
request to "/xx/yy"  => match
request to "/xx//yy" => match

<Location "/xx//yy">
request to "/xx/yy"  => no match
request to "/xx//yy" => no match

<Location "/xx/yy">
request to "/xx/yy"  => match
request to "/xx//yy" => match


2) with: MergeSlashes Off
<LocationMatch "^/xx//yy$">
request to "/xx/yy"  => no match
request to "/xx//yy" => match

<LocationMatch "^/xx/yy$">
request to "/xx/yy"  => match
request to "/xx//yy" => no match

<Location "/xx//yy">
request to "/xx/yy"  => no match
request to "/xx//yy" => match

<Location "/xx/yy">
request to "/xx/yy"  => match
request to "/xx//yy" => no match


In principle these are the results one would expect, BUT.

a) the Location/LocationMatch documentation never exactly tells what is actually folded, the / of the request or of the pattern... so strictly speaking, the documentation is ambiguous and if a use assume it would fold it from the pattern he wouldn't understand the results.

b) That (non-regex) <Location> can have multiple consecutive / is not really explained either... 
The
  "But when (non-regex) <Location> is used for non-proxy requests it will implicitly match multiple slashes with a single slash."
is anyway wrong, as it actually depends on MergeSlashes, which is not mentioned there.
But even then it's not directly clear that <Location "/xx//yy"> (which conceptually makes not that much sense for non-regex) really matches literally and requires //.
Comment 2 Christoph Anton Mitterer 2021-04-13 00:34:24 UTC
Oh and I just realised that MergeSlashes' documentation is also wrong.

It says:
" In these cases MergeSlashes can be set to OFF to retain the multiple consecutive slashes. In these configurations, regular expressions used in the configuration file that match the path component of the URL (LocationMatch, RewriteRule, ...) need to take into account multiple consecutive slashes."

But actually, both On AND Off need to be taken into account... AND not just for regex-versions but apparently also for (non-regex) <Location>.