Escape names already starting with prefix in Base64NameProcessor - #886
Open
Sahana2524 wants to merge 1 commit into
Open
Escape names already starting with prefix in Base64NameProcessor#886Sahana2524 wants to merge 1 commit into
Base64NameProcessor#886Sahana2524 wants to merge 1 commit into
Conversation
encodeName() escaped only names that were not valid XML names, but decodeName() base64-decodes anything carrying the prefix, so a valid name already starting with it did not survive a round-trip.
🧪 Code Coverage Report
|
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
1 participant
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.
The prefixed base64 name processor escapes on write but decodes on read using different conditions, so a name that already starts with the prefix does not survive a round-trip:
encodeName()escapes only names that failVALID_XML_NAME, sobase64_tag_YWRtaW4is a valid XML name and goes out as-isdecodeName()decodes anything starting with the prefix, so that same name reads back asadminbase64_tag_hello) the read fails instead, which is how I noticed itEscaping prefixed names too makes the decode-side prefix test exact, so the mapping is one-to-one again. Names that do not start with the prefix encode exactly as before. The javadoc had this as a caller obligation ("you must ensure that no incoming element or attribute name starts with prefix") - that seemed worth moving into the processor, since with map keys the names are usually not the caller's to choose. Left
AlwaysOnBase64NameProcessoralone: it encodes and decodes every name, so it is already symmetric.