The following query:
module namespace foo = "http://www.zorba-xquery.com/foo";
declare function foo:test() {
if (fn:true())
then 1
else $a
};
(which is in the Zorba source as bin/test/mymod.xq) actually contacts www.zorba-xquery.com via HTTP and attempts to download /foo.xq. This means that the module namespace URI is undergoing URI resolution. I cannot imagine why this would be the case, but it leads not only to slowness but can cause the query to change behaviour depending on what www.zorba-xquery.com chooses to return. (In the original test case, the URL was at 28msec.com, and when 28msec.com changed from raising a 404 error to returning a 200 with an error HTML page, the query started failing with a compilation error. Apparently Zorba was attempting to actually compile the HTML as an XQuery.)
I have figured out that this only happens when compiling the query as a library module, as with the -l command-line option. This happens because Zorba actually creates a separate query that imports the module namespace and executes that, registering a custom URLResolver for that namespace URI that returns the original query.
The reason this ends up hitting the web is because the full URI mapping is also done. So, in this case, the URL "http://
The fix is easy enough - simplify the custom URLResolver so it doesn't even check the URL it is passed. We know it will always be the URL we are expecting, even if it's been modified by URI Mapping, so we can just return the query file resource directly. Tested locally and this works.