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