Bug 65073

Summary:	<LocationMatch> claims consecutive slashes were not matched, while MergeSlashes claims the opposite
Product:	Apache httpd-2	Reporter:	Christoph Anton Mitterer <calestyo>
Component:	Documentation	Assignee:	HTTP Server Documentation List <docs>
Status:	NEW ---
Severity:	major
Priority:	P2
Version:	2.5-HEAD
Target Milestone:	---
Hardware:	All
OS:	All

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>.