Q: What happens when you ask IE to apply XSL to a XML document, while also issuing redirects between HTTP and HTTPS?
A:Not much.
UPDATE: IE 6 results added
App delivers XML to user agent. The XML includes a reference to an XSLT which can be used to convert it to html. IE, acting as a user agent, will retrieve the xsl file and apply it, no problem.
This assumes that the protocol specified to retrieve the XSL matches that used to fetch the XML. Otherwise IE renders an Access denied error, with further information identifying the xsl.
The xml, in our case, doesn't specify the protocol - it offers a relative location to the xsl. And we still have problems, sometimes.
Why? Mixed mode again. In this particular case, the webserver responded to our HTTPS login with a redirect to an HTTP home page. The home page has no sensitive data on it, so there's no security concern here, and the XML reaches the user agent without any trouble, but IE just doesn't like the fact that it now has to fetch the XSL on the insecure channel. So it doesn't bother. Instead, it immediately renders an Access denied error, this time without the reference to the xsl.
Further testing discovers the same symptoms when the protocols are reversed (XML obtained via a secure redirect of an insecure request also can't access the XSL).
This testing was all in IE 5.5.
UPDATE: IE 6.0 is improved. The behavior matrix is the same as 5.5, but the "Access is denied." with no further information is replaced with "Access is denied. Error processing resource", but here the resource listed is the original url (that we've been redirected away from), rather than the xsl file.
February 13, 2003 1:36 PM
| TrackBack