🐛 FIX: Correctly encode "&" in Markdown URLs by not HTML-escaping refuri - #1126
Merged
Conversation
`escapeHtml` was called on the URL before storing it in the `refuri` attribute of a reference node, converting `&` to `&`. This caused double-escaping when Sphinx's HTML writer later escaped the `&` in `&` to produce `&amp;` in the final `href` attribute, breaking URLs with query parameters. The `refuri` attribute should hold the raw URL; HTML-escaping is the responsibility of the output writer. The other characters `escapeHtml` converts (`<`, `>`, `"`) are already percent-encoded by `normalizeLink` before reaching this point, so removing the call has no other effect.
This was referenced Apr 23, 2026
|
Hi @mb , What is still needed to get this upstream? Can I assist? |
Contributor
Author
|
Review from maintainers needed. Not sure if there is anything you can assist with. I think this patch is good as-is and hopefully includes enough test coverage to make review easy. I'm happy to update the patch if necessary. |
|
Thanks @mb and @chrisjsewell! I really appreciate your efforts to get this fix out. |
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
3 participants
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.
escapeHtmlwas called on the URL before storing it in therefuriattribute of a reference node, converting&to&. This caused double-escaping when Sphinx's HTML writer later escaped the&in&to produce&amp;in the finalhrefattribute, breaking URLs with query parameters.The
refuriattribute should hold the raw URL; HTML-escaping is the responsibility of the output writer. The other charactersescapeHtmlconverts (<,>,") are already percent-encoded bynormalizeLinkbefore reaching this point, so removing the call has no other effect.Found while taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=2023603.
Discovered that there exist a similar patch shortly before creating this pull request. So this is an alternative approach to #929. I've imported the tests from the other patch to verify that the patch behaves the same.
Would fix #760, fix #1028, and fix #1116.