v3.2: Update RFC1866 to WHATWG-URL for application/x-www-form-urlencoded #4905
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
handrews
added
clarification
ralfhandl
previously approved these changes
Aug 22, 2025
Co-authored-by: Mike Kistler <[email protected]>
ralfhandl
approved these changes
Aug 22, 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.
This updates our reference for
application/x-www-form-urlencoded. The question of whether it is strictly compatible is very hard to answer, as RFC1866 paraphrases RFC1738 incorrectly, and implementations that I can find that use these don't behave quite like either the paraphrase or the actual requirements. Which are hard to figure out in the first place.Given that we are defining percent-encoding in terms of whether you can successfully decode the encoded string, this is compatible. If we think in terms of exactly what gets encoded, it's not, but also it's probably never been implemented "correctly" because I've never seen a library that percent-encoded every non-alphanumeric character (RFC1866's paraphrase), and the most strict reading of RFC1738 is problematic in terms of its successor, RFC3986, although all in weird corners that would take several more paragraphs to explain.
I think this update is an improvement, as it brings us in line with the current IANA-registered specification for
form-urlencoded, and is less of a nightmare to try to understand by reading the source specifications.