Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix escaping in part name normalization #20

Merged

Conversation

cristiancreteanu
Copy link
Contributor

The iteration of reading the input string of the function was problematic. When finding a pre-encoded character, for instance %28 (which is an open bracket - '('), all three characters were written in the destination string, but the reading of the input string continued with the character after '%', which was '2'. The correct behavior is for the reading to continue with the character after '8'.

The writing in the destination also had a bug. Instead of writing the 3 characters ('%', '2' and '8') one after another, the first two were written correctly, namely at position j and j+1 in the destination string, but the third character was written at j+3 instead of at j+2.

This problem had not appeared before in the tests in part_test.go, because there was no test case that has both a pre-encoded character and a character to be encoded. When there are no characters to be encoded in the input string, the string is returned as it was given in the input. Such a test case would have resulted in an index out of range error.

The iteration of reading the input string of the function was
problematic. When finding a pre-encoded character, for instance
%28 (which is an open bracket - '('), all three characters were
written in the destination string, but the reading of the input
string continued with the character after '%', which was '2'. The
correct behavior is for the reading to continue with the character
after '8'.

The writing in the destination also had a bug. Instead of writing
the 3 characters ('%', '2' and '8') one after another, the first
two were written correctly, namely at position j and j+1 in the
destination string, but the third character was written at j+3
instead of at j+2.

This problem had not appeared before in the tests in part_test,
because there was no test case that has both a pre-encoded
character and a character to be encoded. When there are no
characters to be encoded in the input string, the string is
returned as it was given in the input. Such a test case would have
resulted in an index out of range error.
@qmuntal
Copy link
Owner

qmuntal commented Nov 30, 2023

Thanks for reporting and sending a fix!

@qmuntal qmuntal merged commit 376b40c into qmuntal:master Dec 1, 2023
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants