Don't escape entities in CDATA sections#633
Merged
amitguptagwl merged 1 commit intoNaturalIntelligence:masterfrom Jan 19, 2024
wackbyte:cdata
Merged
Don't escape entities in CDATA sections#633amitguptagwl merged 1 commit intoNaturalIntelligence:masterfrom wackbyte:cdata
amitguptagwl merged 1 commit intoNaturalIntelligence:masterfrom
wackbyte:cdata
Conversation
Member
|
Thanks for you PR. let me check |
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.
Purpose / Goal
Changes the parsing of CDATA sections to not escape entities.
In other words:
<[CDATA[&]]>->&<[CDATA[&]]>->&I also added a new test so that this behavior can be tested on its own.
Please note that I did not attempt to avoid any breaking changes here as the issue suggested, but if it is desired, I would be happy to gate this fix behind a new option.
The contents of a CDATA section will also now be run through
tagValueProcessoreven when thecdataPropNameoption is provided. I am unsure as to if this inconsistency was intentional (the code that would have made it consistent seems to have been commented out a while ago), so if that is considered an unrelated change, I would also be happy to split it out into a separate PR.Closes #632.
Performance tests
Before:
After:
Type
Please mention the type of PR