Project

Profile

Help

Bug #5949

open

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

Added by Norm Tovey-Walsh 2 months ago. Updated about 2 months ago.

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

0%

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

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 2 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 2 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 2 months ago

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

Actions #4

Updated by Norm Tovey-Walsh 2 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 about 2 months ago

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

Just leaving this on your plate for review...

Please register to edit this issue

Also available in: Atom PDF