In REST Assured, which XmlConfig switches decide whether a DOCTYPE in a response parses?

## The switches and their defaults `io.restassured.config.XmlConfig` holds three parser booleans and two open-ended maps, plus the namespace declarations. Only the first group concerns DOCTYPEs and DTDs: | Setting | Default | What it controls | |---|---|---| | `allowDocTypeDeclaration(boolean)` | `false` | whether a `<!DOCTYPE ...>` in the body is tolerated at all | | `validating(boolean)` | `false` | whether the parser validates the document as it parses | | `namespaceAware(boolean)` | `true` | whether parsing takes namespaces into account | | `disableLoadingOfExternalDtd()` | not set | shortcut that adds one feature: `nonvalidating/load-external-dtd` = `false` | | `feature(uri, enabled)` / `features(Map)` | empty | any SAX feature, applied after the parser is built | | `property(name, value)` / `properties(Map)` | empty | any SAX property, applied after the parser is built | The three booleans go straight into `new XmlSlurper(validating, namespaceAware, allowDocTypeDeclaration)` — and only in `XmlPath.CompatibilityMode.XML`. Each one's Javadoc says so explicitly, and the HTML branch calls the single-argument constructor over tagsoup, which those arguments never reach. ## Why a DOCTYPE fails out of the box An orchard spray-diary service with a SOAP-era ancestry still emits: ```xml <!DOCTYPE sprayDiary SYSTEM "http://orchard.example/dtd/spray-diary.dtd"> <sprayDiary season="2026">...</sprayDiary> ``` With `allowDocTypeDeclaration` left at its default `false`, the slurper is built with the underlying reader's `disallow-doctype-decl` feature turned on, and parsing fails on the declaration itself — before any GPath step is evaluated. There is no partial read and no useful path-level message: a standalone `XmlPath` wraps the cause in an `XmlPathException` reading *Failed to parse the XML document*. The tell is that **every** path against that response fails at once, including trivially correct ones. ## Two DTD switches, doing two different jobs 1. `allowDocTypeDeclaration(true)` permits the declaration to exist. Without it nothing else matters, because the parse dies at the first line. 2. `disableLoadingOfExternalDtd()` stops the parser from going out and *fetching* what the declaration points at. It is a shortcut for `feature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false)`. They are independent, and a legacy endpoint typically wants both: tolerate the declaration, refuse the network fetch. Skipping the second leaves your suite quietly dependent on a DTD host that may be slow, firewalled, or gone. ## An asymmetry between the two config classes The DSL-side `XmlConfig` and the standalone-side `XmlPathConfig` both offer `disableLoadingOfExternalDtd()`, with the same name and near-identical Javadoc, and they do **not** do the same thing: - `XmlConfig.disableLoadingOfExternalDtd()` adds exactly one feature: `nonvalidating/load-external-dtd` = `false`. - `XmlPathConfig.disableLoadingOfExternalDtd()` adds two: that one **and** `disallow-doctype-decl` = `false`. So `new XmlPath(xml).using(xmlPathConfig().with().disableLoadingOfExternalDtd())` reads a DOCTYPE-bearing document on its own, while the same-named call on the DSL side does not — there you also need `allowDocTypeDeclaration(true)`. If you have ever ported a working standalone snippet into a `given().config(...)` chain and watched it stop working, this is why. ## Features and properties are the real escape hatch - `feature(uri, enabled)` and `features(Map)` set any SAX feature by URI; `property(name, value)` and `properties(Map)` set any SAX property. - Both maps are applied **after** the slurper is constructed, so a feature can override a constructor boolean: setting `disallow-doctype-decl` to `false` directly has the same net effect as `allowDocTypeDeclaration(true)`. - Unlike the three booleans, features and properties are applied in both compatibility modes. - Every one of these methods returns a **new** `XmlConfig` rather than mutating the receiver, so chain them and assign the result; a stray `xmlConfig().allowDocTypeDeclaration(true);` on its own line does nothing. - Applying it is the usual three-way choice: `RestAssured.config = ...` globally, `RequestSpecBuilder.setConfig(...)` on a spec, or `given().config(...)` for one call. ## Judgment - Leave `allowDocTypeDeclaration` at `false` unless a specific endpoint forces your hand. A parser that refuses DOCTYPEs is the safer default, and it is the shipped one. - When you must switch it on, scope it: `given().config(...)` on the one call, not `RestAssured.config` for the whole suite. The blast radius of a global relaxation is every test in the run. - Pair it with `disableLoadingOfExternalDtd()` so the parser never dials out to resolve the declaration. - Treat the switch as a documented exception with a named endpoint beside it in review, not as a knob someone flips to make a red test go green. - Keep `validating(false)`. Turning validation on couples your assertions to a schema fetched at parse time, which is a different job from asserting on values.