Repository navigation
Reject processing instructions with reserved xml target - #1037
johnozler-hunt wants to merge 1 commit into
Conversation
emit_question_mark routed a processing instruction to a Decl event only when its target was the exact lowercase `xml`, and emitted every other spelling (`<?XML?>`, `<?XmL?>`, `<?xMl?>`) as a PI event. The PITarget production reserves `xml` in any combination of case, so conforming parsers reject those while quick-xml accepted them. Return the new IllFormedError::ReservedPiTarget when a PI target equals `xml` ignoring ASCII case. The lowercase declaration is unaffected.
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1037 +/- ##
==========================================
+ Coverage 53.71% 53.82% +0.10%
==========================================
Files 51 51
Lines 19412 19522 +110
==========================================
+ Hits 10428 10508 +80
- Misses 8984 9014 +30
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Unfortunately not, some quick-xml consumers rely on the fact that they will have access to the We do not want to restrict PI on core parser level. That should be done in the explicit validation pass. I have some thoughts in my validation branch, how that could look. |
When the reader splits
<?...?>,emit_question_markdecides between a declaration and a processing instruction by testing the target with a case-sensitivestarts_with(b"xml"). Only the exact lowercase form becomes aDecl; every other spelling of the target falls through to the PI branch, so<?XML?>,<?XmL?>and<?xMl?>were emitted as ordinaryPIevents. The PITarget production reservesxmlin any combination of upper and lower case (it is kept for the declaration), so these are not well-formed: libxml2 and expat reject them as an invalid token, while quick-xml accepted them. That disagreement is the kind of parser differential that lets a crafted<?XML ...?>slip past a quick-xml based tool and be read as a declaration by the next parser in a pipeline. I hit it while probing PI handling against expat. The fix returns a newIllFormedError::ReservedPiTargetwhen the target equalsxmlignoring ASCII case; the lowercase<?xml?>declaration and targets likexmlxare unchanged.