Bug 66133 - uri and parsed_uri not truncated for multiple slashes
Summary: uri and parsed_uri not truncated for multiple slashes
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_request (show other bugs)
Version: 2.4.52
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2022-06-21 15:36 UTC by Akash
Modified: 2022-06-21 17:23 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
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..