Saxon parsed XSL stylesheet cannot access remote resources

Question

Trying to parse an XSLT 2.0 stylesheet with Saxon HE, getting the following error:

Error on line 44 column 168 
  XTSE0165: I/O error reported by XML parser processing
  http://www.loc.gov/standards/mods/inc/mimeType.xsl: Server returned HTTP response code:
  403 for URL: http://www.loc.gov/standards/mods/inc/mimeType.xsl

This stylesheet contains a handful of remote resources it attempts to retrieve:

<xsl:include href="http://www.loc.gov/standards/mods/inc/dcmiType.xsl"/>
<xsl:include href="http://www.loc.gov/standards/mods/inc/mimeType.xsl"/>
<xsl:include href="http://www.loc.gov/standards/mods/inc/csdgm.xsl"/>
<xsl:include href="http://www.loc.gov/standards/mods/inc/forms.xsl"/>
<xsl:include href="http://www.loc.gov/standards/mods/inc/iso3166-1.xsl"/>
<xsl:include href="http://www.loc.gov/standards/mods/inc/iso639-2.xsl"/>

However, I have confirmed that all the links are valid and be retrieved via a browser or curl. Additionally, when I serve those files on localhost, and change the <xsl:include> accordingly, I do not get the 403 error.

My question, is there some kind Saxon or Java setting that is preventing Saxon HE from accessing resources not on localhost?

Many thanks in advance for any suggestions.

Update: I'm using pyjxslt as a server to perform the Saxon transformations, running at localhost:6767.

You have tagged your question with the error code you get and if you read the description of that tag it clearly says " the server refuses to respond to the request" so it is not a problem of Saxon but rather one of the server refusing to serve the stylesheet. — Martin Honnen
Yes, but for all those URLs listed in the stylesheet, they are accessible through browser or curl, without any 403 errors. So why would Saxon -- or perhaps more accurately, the XSLT stylesheet -- requesting the documents result in a 403? — ghukill
I don't know, it could for instance be because of user agent settings that are different between a browser and the Java net APIs. You could sniff the HTTP request/responses between your machine and the server and try to compare the ones from the browser to the ones done by Saxon. — Martin Honnen
That's where I was going next, thanks for the sanity check. Must be something in the request. — ghukill
FWIW I get the same effect: I can access these URLs using Safari, but not using the one-line query doc('loc.gov/standards/mods/inc/dcmiType.xsl') run from the command line. — Michael Kay

Michael Kay Michael Kay · Accepted Answer · 2017-11-17T17:22:58

I tried this using the doc() function from the XQuery command line, using "Charles" to monitor the HTTP traffic.

The detailed HTTP response says that the site is using Cloudflare to restrict access, and that it has refused access "based on your browser's signature".

So unless you can insert some kind of proxy to change the browser signature in the request, or persuade the owners of the site that their security policy makes no sense, you may be out of luck.

One thing I notice is that Safari includes "accept application/xml" in the HTTP request header, and Java does not. It's possible that the site has somehow been configured not to serve XML unless the request header says it will accept XML. I haven't seen this happen before, but it's something to investigate.

Incidentally, by default Saxon doesn't call the Java APIs directly to get a document; if you use the standard (default) URIResolver then this creates an InputSource object wrapping the requested URL, and the InputSource is passed to the XML parser which then calls Java to fetch the resource. I don't know which Java APIs the XML parser is actually using. But if you can find a way that works, you could bypass this by writing a URIResolver that configures an HTTP request and gets an InputStream directly.

Saxon parsed XSL stylesheet cannot access remote resources

1 Answers