Saxon

Very strange.

The error message comes from StandardUnparsedTextResolver.java which does:

            try {
                absoluteURL = absoluteURI.toURL();
            } catch (MalformedURLException mue) {
                XPathException e = new XPathException("Cannot convert absolute URI "
                                                              + absoluteURI + " to URL", mue);
                e.setErrorCode("FOUT1170");
                throw e;
            }

So absoluteURI.toURL() is throwing "unknown protocol: https". And of course this is happening in the OpenJDK implementation as compiled using IKVMC. It's probably invoking some kind of protocol handler beneath the scenes, which probably calls into the .NET libraries.

(I would have assumed that URI.toURL() is a purely syntactic operation on the URI, but a similar error in Websphere reported at https://www.ibm.com/support/pages/error-message-might-display-when-https-specified hints that you could get this failure if a required protocol handler isn't found.)

Sadly Jeroen is no longer around to help us.

Do you customise the UnparsedTextResolver at all?

Yes, I have a subclass basically blocking file URI :

    public class SecureTextResolver : StandardUnparsedTextResolver
    {
        public override java.io.Reader resolve(URI absoluteURI, string encoding, Configuration config)
        {
            if (absoluteURI.getScheme() == "file")
            {
                throw new net.sf.saxon.trans.XPathException("No file: URI access for unparsed-text function.");
            }
            return base.resolve(absoluteURI, encoding, config);
        }
    }

which I use with e.g. processor.Implementation.setConfigurationProperty("http://saxon.sf.net/feature/unparsedTextURIResolver", new SecureTextResolver());.

That shouldn't do anything different for HTTP(S) than the default text resolver.

I will need to check the repository for the XQuery fiddle, but I think it does the same.

The XQuery fiddle has the same subclass code.

I am still clueless as to what causes the difference that the XSLT fiddle has that problem with https while the XQuery fiddle does fine.

Certainly, at that level Saxon is executing exactly the same code for XSLT and XQuery.

Does it apply to all "https" URIs?

(Presumably the URI in the error message is actually the URI you requested, not https://example.com/ ...?)

The subject URI is just to have a short description, the text itself has "real" sample URIs like https://restcountries.com/v2/alpha/de. Your comment about protocols made me remember that IKVM needed some <add key="ikvm:https.protocols" value="TLSv1,TLSv1.1,TLSv1.2" /> web.config setting to have a better HTTPS support, I think previously the error (without that config key) was kind of different, only breaking some websites.

I am pretty sure the XSLT fiddle had that config section, will need to check whether during some unrelated updated I managed to use a web.config without that setting. Will check and report later whether there is a difference and whether adding the section fixes the problem.

Thanks so far.

No, the XSLT fiddle has that setting in the web.config, like the XQuery fiddle.

For today I am kind of done, already shot myself in the foot accessing some file on my hoster's account (although it looks they had put some quota on the account causing that, so not my fault, entirely).

I will check tomorrow or back during the week whether I can spot some other differences between the two projects that could explain it.

It seems any HTTPS (text?) URIs fail, even a plain

      <xsl:try select="unparsed-text('https://example.com/')">
        <xsl:catch expand-text="yes">{$err:code, $err:description, $err:value, $err:line-number}</xsl:catch>
      </xsl:try>

gives the error.

doc works

    <section>
      <h3>doc test</h3>
      <xsl:try select="doc('https://martin-honnen.github.io/xslt3fiddle/examples/defaults/default.xml')">
        <xsl:catch expand-text="yes">{$err:code, $err:description, $err:value, $err:line-number}</xsl:catch>
      </xsl:try>
    </section>

unparsed-text fails:

    <section>
      <h3>unparsed-text test</h3>
      <xsl:try select="unparsed-text('https://martin-honnen.github.io/xslt3fiddle/examples/defaults/default.xml')">
        <xsl:catch expand-text="yes">{$err:code, $err:description, $err:value, $err:line-number}</xsl:catch>
      </xsl:try>
    </section>

Interesting. The doc() function, I think, delegates URI dereferencing to the XML parser (which by default is the IKVM-cross-compiled version of Apache Xerces - unless you change settings to use the Microsoft parser.)