Project

Profile

Help

Bug #5949

closed

A resource loaded via the resolver vs one loaded "directly" is a different source with different options

Added by Norm Tovey-Walsh 11 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2023-03-31
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
11, 12, trunk
Fix Committed on Branch:
11, 12, trunk
Fixed in Maintenance Release:
Platforms:
Java

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.

Actions #1

Updated by Norm Tovey-Walsh 11 months ago

  • Applies to branch 11, 12, trunk added

This probably applies to 11 as well, but I haven't actually tested that.

Actions #2

Updated by Norm Tovey-Walsh 11 months 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?

Actions #3

Updated by Norm Tovey-Walsh 11 months ago

It's not completely safe because it causes TestXMLParserOptions.testSettingOfProperty to fail. :-(

Actions #4

Updated by Norm Tovey-Walsh 11 months ago

The way options.merge() is written, options.merge(options) is destructive so my "fix" only works because it accidentally removes some validatin properties. :-(

Actions #7

Updated by Norm Tovey-Walsh 11 months ago

  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

Just leaving this on your plate for review...

Actions #10

Updated by Norm Tovey-Walsh 4 months ago

  • Status changed from New to Closed

Apparently resolved.

Actions #11

Updated by Norm Tovey-Walsh 3 months ago

  • Status changed from Closed to In Progress

This bug is not resolved.

Actions #12

Updated by Michael Kay 3 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.

Actions #13

Updated by Michael Kay 3 months ago

  • Fix Committed on Branch 11 added
  • Platforms Java added
Actions #14

Updated by O'Neil Delpratt 3 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

Also available in: Atom PDF