[Bug 66133] New: uri and parsed_uri not truncated for multiple slashes

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66133

            Bug ID: 66133
           Summary: uri and parsed_uri not truncated for multiple slashes
           Product: Apache httpd-2
           Version: 2.4.52
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_request
          Assignee: bugs@httpd.apache.org
          Reporter: akashzambre@ymail.com
  Target Milestone: ---

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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 66133] uri and parsed_uri not truncated for multiple slashes

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66133

Yann Ylavic <yl...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All

--- Comment #1 from Yann Ylavic <yl...@gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 66133] uri and parsed_uri not truncated for multiple slashes

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66133

--- Comment #2 from Akash <ak...@ymail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 66133] uri and parsed_uri not truncated for multiple slashes

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66133

--- Comment #3 from Yann Ylavic <yl...@gmail.com> ---
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..

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org