Repository navigation
Limit how deep the parser nests elements, as the HTML parser does - #42
Merged
FlorianRappl merged 2 commits intoNov 2, 2026
Merged
Conversation
XmlParserOptions.MaximumDepth mirrors core's HtmlParserOptions.MaximumDepth: the deepest level the parser nests elements at, counting the root as level 1, defaulting to 512; zero or a negative value restores the default and Int32.MaxValue lifts the limit. An element beyond it throws MaximumDepthExceeded (0x314), since nesting it elsewhere changes an XML document; with IsSuppressingErrors it is attached at the limit as a sibling of the deepest element, as the HTML parser does. The deep-nesting tests and the deep benchmark shapes go beyond 512 levels to exercise the explicit-stack walks, so they lift the limit.
FlorianRappl
reviewed
Nov 1, 2026
| - Fixed unbounded expansion of nested entities ("billion laughs"), which let a small document exhaust memory; expansion now stops at `XmlParserOptions.MaxCharactersFromEntities` | ||
| - Added trimming and Native AOT compatibility (`IsAotCompatible`) for the .NET 8 and .NET 10 targets | ||
| - Added `XmlParserOptions.MaxCharactersFromEntities` (default 10,000,000, 0 for no limit), like `System.Xml`'s setting of the same name | ||
| - Added `XmlParserOptions.MaximumDepth` (default 512), like `HtmlParserOptions.MaximumDepth`: deeper elements throw, or are attached at the limit when errors are suppressed (breaking for documents nested deeper than 512 levels) |
Contributor
There was a problem hiding this comment.
Would remove the (breaking for documents nested deeper than 512 levels). Those are most likely hostile documents.
In any other case somebody needs to change the default, which is imho fine as it uncovers that there are some potentially ill-formed documents being parsed.
FlorianRappl
approved these changes
Nov 2, 2026
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.
Follows up on #39: the XML parser gets the same nesting limit as core's HTML parser.
Change
XmlParserOptions.MaximumDepthmirrors core'sHtmlParserOptions.MaximumDepth:XmlParserOptions.DefaultMaximumDepth);Int32.MaxValuelifts the limit.XmlParseError.MaximumDepthExceeded(0x314), because nesting the element elsewhere would change an XML document.IsSuppressingErrors, the element is attached at the limit as a sibling of the deepest element, as the HTML parser does. Text that follows a closed sibling stays in its own element.Tests
XmlMaximumDepthcovers:Int32.MaxValue;621 tests pass.
🤖 Generated with Claude Code