Bug #5949
closedA resource loaded via the resolver vs one loaded "directly" is a different source with different options
100%
Description
The resolveWithFileURI()
and resolveWithHttpURI()
tests in src/tests/java/resolvers/CatalogResolverTest
demonstrate this bug.
The test enables DTD validation for the input source. The stylesheet also loads an ancillary document with the doc()
function.
When doc()
loads a file off disk (another XSL stylesheet, in this case), the DirectResourceResolver
loads it and returns an AugmentedSource
. When that source configures a parser, it does so with options that have been passed through options.merge()
that also specify a bunch of settings, including DTD validation (off).
When doc()
loads (the same file) but with a resource returned by the resolver, the catalog resolver returns a TypedStreamSource
. When that source configures a parser, it doesn't use merging and seems to inherit a bunch of options from the builder. Including DTD validation which causes doc()
to fail because there's no doctype declaration in the XSL file.
Updated by Norm Tovey-Walsh over 1 year ago
- Applies to branch 11, 12, trunk added
This probably applies to 11 as well, but I haven't actually tested that.
Updated by Norm Tovey-Walsh over 1 year ago
On the "load from file" path, where we pass through resolveSource()
on Configuration
, we find
@Override
public void deliver(Receiver receiver, ParseOptions options) throws XPathException {
options = options.merge(((AugmentedSource) source).getParseOptions());
resolveSource(((AugmentedSource) source).getContainedSource(), config)
.deliver(receiver, options);
}
On the "load from URI path" we don't get an AugmentedSource
and we pass through deliver
on ActiveSAXSource
:
@Override
public void deliver(Receiver receiver, ParseOptions options) throws XPathException {
try {
Logger logger = receiver.getPipelineConfiguration().getConfiguration().getLogger();
XMLReader parser = getXMLReader();
//System.err.println("Using parser " + parser.getClass());
configureParser(parser); // Bug 5276
which doesn't call options.merge()
and so doesn't get a bunch of defaulted settings. If I change deliver()
in ActiveSAXSource
by adding
options = options.merge(options);
just before configureParser(parser); // Bug 5276
, then the HTTP case passes.
But is that safe? And are there other places where we should do this?
Updated by Norm Tovey-Walsh over 1 year ago
It's not completely safe because it causes TestXMLParserOptions.testSettingOfProperty
to fail. :-(
Updated by Norm Tovey-Walsh over 1 year ago
The way options.merge()
is written, options.merge(options)
is destructive so my "fix" only works because it accidentally removes some validatin properties. :-(
Updated by Norm Tovey-Walsh over 1 year ago
- Assignee set to Michael Kay
- Priority changed from Low to Normal
Just leaving this on your plate for review...
Updated by Norm Tovey-Walsh 11 months ago
- Status changed from Closed to In Progress
This bug is not resolved.
Updated by Michael Kay 11 months ago
- Status changed from In Progress to Resolved
- Fix Committed on Branch 12, trunk added
The problem turned out to be that an XML parser (source parser) was being reused from the parser pool, but was not being reconfigured to switch off DTD validation. Code added to ActiveStreamSource
so that when a parser is taken from the pool held by the Configuration, the property controlling DTD validation is always explicitly set on or off.
Updated by Michael Kay 11 months ago
- Fix Committed on Branch 11 added
- Platforms Java added
Updated by O'Neil Delpratt 11 months ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.4 added
Bug fix applied in the Saxon 12.4 Maintenance release
Please register to edit this issue