uri: Fix normalization memory management for uri_parser_php_parse_url.c #19600
+149
−29
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6c6197e to
cd01b22
Compare
nielsdos
reviewed
Aug 26, 2025
| @@ -724,6 +725,67 @@ static ZEND_FUNCTION(zend_test_crash) | |||
| php_printf("%s", invalid); | |||
| } | |||
|
|
|||
| static ZEND_FUNCTION(zend_test_uri_parser) | |||
There was a problem hiding this comment.
What I've done for DOM once is define a debugging function under #if ZEND_DEBUG. Doing that here too would keep the uri stuff in ext/uri.
There was a problem hiding this comment.
I'll leave the decision to Máté 😃
There was a problem hiding this comment.
I'm fine with adding this function to ext/zend_test. :) It doesn't make it more difficult for any tooling to parse stub files.
E.g. adding any symbol to stub files that is not for production should have the @undocumentable phpdoc, otherwise the documentation generator tries to sync it with the manual. AFAIK PHPStan also parses these files. So 👍 overall!
There were two issues with the previous implementation of normalization: - `php_raw_url_decode_ex()` would be used to modify a string with RC >1. - The return value of `php_raw_url_decode_ex()` was not used, resulting in incorrect string lengths when percent-encoded characters are decoded. Additionally there was a bogus assertion that verified that strings returned from the read handlers are RC =2, which was not the case for the `parse_url`-based parser when repeatedly retrieving a component even without normalization happening. Remove that assertion, since its usefulness is questionable. Any obvious data type issues with read handlers should be detectable when testing during development.
cd01b22 to
ad9e557
Compare
kocsismate
approved these changes
Aug 26, 2025
TimWolla
added a commit
that referenced
this pull request
Aug 26, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There were two issues with the previous implementation of normalization:
php_raw_url_decode_ex()would be used to modify a string with RC >1.php_raw_url_decode_ex()was not used, resulting in incorrect string lengths when percent-encoded characters are decoded.Additionally there was a bogus assertion that verified that strings returned from the read handlers are RC =2, which was not the case for the
parse_url-based parser when repeatedly retrieving a component even without normalization happening. Remove that assertion, since its usefulness is questionable. Any obvious data type issues with read handlers should be detectable when testing during development.This is a follow-up for the issue detected in #19587.