XML Parser Recovery Behavior After Well-Formedness Errors Lacks Standardization

Answer the question first

There is no standardized way to continue parsing after a well‑formedness error; the XML 1.0 spec treats such errors as fatal. Consequently, portable recovery depends on either rejecting malformed input outright or wrapping each parser in a layer that normalizes its output.

Confirmed facts

• XML 1.0 Fifth Edition, Section 2.1 requires a well‑formedness error to be fatal and prohibits normal processing continuation.
• Xerces (continueAfterFatalError), libxml2 (XML_PARSE_RECOVER), and MSXML (via setProperty with SAXProperty::http://apache.org/xml/features/continue-after-fatal-error or DOM flags) each expose a non‑standard recovery flag that allows the parser to attempt recovery.
• When these flags are enabled, the resulting document trees, error reports, and heuristic decisions differ significantly between implementations and may not correspond to any well‑formed XML document.

Likely explanation for the lack of standardization

The spec deliberately forbids continuation to guarantee deterministic error handling. Vendors added proprietary recovery modes to improve usability for tolerant applications, but because the spec provides no guidance, each vendor implemented its own heuristics, leading to divergence.

Steps to handle this case in a security‑sensitive application

1. Disable recovery – Use the parser’s strict mode (do not set any recovery flag). This ensures any well‑formedness error aborts parsing, keeping the security boundary clear.
2. Validate before parsing – Apply a quick well‑formedness check (e.g., xmllint --noout or an equivalent SAX‑based validator) and reject the input if it fails.
3. If recovery is unavoidable – Isolate the recovery‑enabled parser in a sandbox, run the same malformed document through at least two different parsers with their recovery flags, compare the produced node counts or checksums, and only accept the result if the outputs match; otherwise, fall back to rejection.
4. Log and monitor – Record the parser used, the recovery flag state, and any discrepancies for audit trails.

Verification you can perform

# Example using xmllint (libxml2) and Xerces C++ command line
xmllint --noout --recover test-bad.xml 2>&1
xerces-c -continueAfterFatalError test-bad.xml 2>&1
# Compare exit codes and any produced output files

Repeat with MSXML via a short script that sets the appropriate property and checks the parse result.

Missing diagnostic detail that would change the recommendation

If your application can tolerate a partial or altered tree (e.g., for best‑effort data extraction), please confirm whether such a tolerance exists; otherwise, the safe path is to reject malformed input outright.