Bug 66133

Summary:	uri and parsed_uri not truncated for multiple slashes
Product:	Apache httpd-2	Reporter:	Akash <akashzambre>
Component:	mod_request	Assignee:	Apache HTTPD Bugs Mailing List <bugs>
Status:	NEW ---
Severity:	normal
Priority:	P2
Version:	2.4.52
Target Milestone:	---
Hardware:	PC
OS:	All

Description Akash 2022-06-21 15:36:31 UTC

Working on upgrade to 2.4.52 version. And have a test in which url has multiple slashes that needs to be truncated.

Looking at this change - https://github.com/apache/httpd/commit/6b3b91a616b4848ee134ef902c785a7b2c0dd453

Before this, ap_no2slash(r->uri) was called. And now it is not which is causing our tests to fail. We see that although parsed_uri.path is truncated, r->uri is not, which eventually leads to failure.
Why this change in behavior for these 2 variables?

Comment 1 Yann Ylavic 2022-06-21 16:01:13 UTC

ap_no2slash() has been replaced by ap_normalize_path(), and a later change (https://github.com/apache/httpd/commit/aaf7e3eb4f21d3aec19381491470a5168a05904a, after the commit you mention) handled slash merging ealier (both change made it to 2.4 at the same time).

What is your test precisely? Because usually r->uri and r->parsed_uri.path are pointing to the same string at this point, so changing r->parsed_uri.path in place should also change the value pointed to by r->uri.

Comment 2 Akash 2022-06-21 16:59:51 UTC

Ya I see that these 2 are pointing to same memory location now, but it was not like that before.
So the test made duplicates of this and separated out memory location for these 2. As a result, uri and parsed_uri are not same and therefore leads to an issue on our end.

Comment 3 Yann Ylavic 2022-06-21 17:23:26 UTC

Well, the old code pretty much assumed that r->uri == r->parsed_uri.path since it called ap_unescape_url() on r->parsed_uri.path but ap_getparents() (or ap_no2slash()) on r->uri.
There are all meant to work on the same location, so the new code is using r->parsed_uri.path consistently.
Actually ap_process_request_internal() is supposed to be called after ap_parse_uri(), which sets both pointers to the same value.

I don't know what your test is doing, but if it had tested for %-decoding from ap_process_request_internal() on r->uri (with r->uri != r->parsed_uri.path), it would have failed long ago since ap_unescape_url() is called on r->parsed_uri.path only..