It seems Safari is the only browser that will leave you left wondering why on earth it — seemingly randomly — refuses to make even the most token attempt at accessing any particular URI via the document function. That’s because each of the other browsers will automatically URL encode GET requests where as Safari will not and as such will throw an internal (I assume internal to the underlying OS?) error. Of course it won’t tell you it through an error which will be the source of significant hair pulling, but none-the-less, an error has been thrown — somewhere. ;-)
I’m not immediately finding anything in the XSLT 1.0 spec that even remotely touches on whether or not it is the job of the transformation engine, the underlying system, or the developer to properly URL encode a request, so I can only assume that regardless of whether or not it’s a pain in the a$$, not URL encoding requests made via the document function is completely within the realm of a standards compliant XSLT processor. Anyone in the know care to clarify?
In the mean time, one of the better resources I’ve found for both quick and easy reference as well as on-the-fly encoding of any given URI is located @ http://www.blooberry.com/indexdot/html/topics/urlencoding.htm. If you find yourself about ready to rip your hair out because Safari refuses to make any attempt at retrieving the document located at any given URI, check the above resource. Chances are pretty good that something as simple as a | character not being properly URL encoded is the culprit.
The URL encoding has always been the programmer's responsibility. All browser functions (including the document() XSLT function and window.open() JavaScript function) are specified to accept URL and if the argument string is not properly encoded, it's simply not a valid URL.
Some browsers are more programmer-friendly than others, though. For example, Internet Explorer has (almost) forever been able to change a space into a %20 by itself, whereas the long-gone Netscape 4 had problems with that (as we've discovered when working with a large customer that used only Netscape internally). It looks like the Safari browser is preserving the venerable Netscape tradition ;)
@Ivan,
>> The URL encoding has always been the programmer's responsibility. All browser functions (including the document() XSLT function and window.open() JavaScript function) are specified to accept URL and if the argument string is not properly encoded, it's simply not a valid URL. > Some browsers are more programmer-friendly than others, though. For example, Internet Explorer has (almost) forever been able to change a space into a %20 by itself, whereas the long-gone Netscape 4 had problems with that (as we've discovered when working with a large customer that used only Netscape internally). > It looks like the Safari browser is preserving the venerable Netscape tradition ;)
>> People still use Netscape 4? Why? <<
Oh, that was years ago; this problem is not new, it only reappears in new places ;)