XML Resolver updates

It turns out that there’s a gap between unit testing and integration testing in the XML Resolver that’s just surfaced. You can configure the resolver to limit access to only selected protocols for entity or document resolution. For example, to limit access to only http: and https: URIs if you’re running untrusted code on your local machine.⊕I think there’s a lot more to realistically sandboxing untrusted code than setting a few library features. If you want to be safe, you want to run the code in some actual sandbox: a container that exists just for that purpose. Running untrusted code on your production systems feels very much like a “your gun, your bullet, your foot” sort of scenario. Be careful out there, people! That prevents a malicious request from accessing documents on your filesystem.

The resolver was correctly detecting this situation and returning a “rejected” request. But because the responses have to be squeezed back through historical APIs, that rejected request eventually got passed back to the application, the parser, as null.

All well and good, and all of the unit tests pass.

Unfortunately, XML parsers in Java often take the position that the resolver is optional. They call the resolver, and if the resolver returns a resource, they use it. But if the resolver returns null, they just attempt to load the original URI.

And therein lies the problem. The resolver returns null and the parser just loads the file: URI directly.

#FAIL

I don’t think there’s any gentle way around this. The XML Resolver tries to be resilient and not throw exceptions. But in this case, I think it has to.

Starting with 6.0.13 (and 5.3.0), if the request is rejected because of protocol restrictions, the resolver throws an IllegalArgumentException.

That’s a change in behavior that I would have preferred to avoid, but it seems preferable letting the parser blithely circumvent the restriction.