Do not escape malformed URI twice when sending ICP errors#2374
Closed
rousskov wants to merge 1 commit intosquid-cache:masterfrom
Closed
Do not escape malformed URI twice when sending ICP errors#2374rousskov wants to merge 1 commit intosquid-cache:masterfrom
rousskov wants to merge 1 commit intosquid-cache:masterfrom
Conversation
Authored-by: Joshua Rogers <megamansec@gmail.com> In this context, escaping escaped URI always produces incorrect URI because `%` character in the escaped URI gets escaped again. Feeding the result of the first rfc1738_escape() call to the second call is also dangerously wrong because the result of the first call gets invalidated during the second call. No other cases of such "chained" rfc1738_escape() calls were found. Broken since 2002 commit e6ccf24.
rousskov
commented
Feb 10, 2026
Contributor
Author
There was a problem hiding this comment.
I developed this fix independently, but I am attributing it to @MegaManSec because Joshua made the same code change in #2220. That PR description does not discuss that change. Since addressing other problems in that PR requires a lot more efforts and may take some time, I decided to post this small fix as a separate PR.
rousskov
added a commit
to MegaManSec/squid
that referenced
this pull request
Feb 10, 2026
This reverts commit 9af3d82. That change is correct, but it addresses a rather different bug, and it may be best to merge it separately (via squid-cache#2374).
kinkie
approved these changes
Feb 10, 2026
yadij
approved these changes
Feb 11, 2026
squid-anubis
pushed a commit
that referenced
this pull request
Feb 11, 2026
In this context, escaping escaped URI always produces incorrect URI because `%` character in the escaped URI gets escaped again. Feeding the result of the first rfc1738_escape() call to the second call is also dangerously wrong because the result of the first call gets invalidated during the second call. No other cases of such "chained" rfc1738_escape() calls were found. Broken since 2002 commit e6ccf24.
squidadm
pushed a commit
to squidadm/squid
that referenced
this pull request
Feb 11, 2026
…e#2374) In this context, escaping escaped URI always produces incorrect URI because `%` character in the escaped URI gets escaped again. Feeding the result of the first rfc1738_escape() call to the second call is also dangerously wrong because the result of the first call gets invalidated during the second call. No other cases of such "chained" rfc1738_escape() calls were found. Broken since 2002 commit e6ccf24.
Collaborator
|
queued for backport to v7 |
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
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.
Authored-by: Joshua Rogers megamansec@gmail.com
In this context, escaping escaped URI always produces incorrect URI
because
%character in the escaped URI gets escaped again. Feeding theresult of the first rfc1738_escape() call to the second call is also
dangerously wrong because the result of the first call gets invalidated
during the second call.
No other cases of such "chained" rfc1738_escape() calls were found.
Broken since 2002 commit e6ccf24.