All I can say is, WOW! I guess I will stick with server-side xslt for now!
There appears to be no reasonable workaround from the server's point of view.
You approach with JavaScript is what my book, Applied XML, recommends, but I
would prefer the content type association myself.
Have you checked to see if this same "double connect" occurs between pages
that are both of type 'text/xml'?
tim.
> Last weekend, I found that the source of my problem was purely IE5 and XML.
> I cobbled a way to test this with Netscape and this problem does not happen
> at all.
>
> I'm basically using JSPs to generate pure XML pages with references to XSL
> stylesheets so that IE5 can do the transformations (instead of using server
> resources). In the following description, I don't mean to suggest that I've
> debugged into IE5 and understand how the IE5 engine actually works--rather
> I'm describing what seems to be the behavior.
>
> Here's the scenario. You're looking at a web page with a link to a JSP. When
> you click this link, the browser requests the JSP page. This JSP emits a
> page directive to change the contentType to "text/xml". It seems that as
> soon as IE5 gets this contentType switch, it abruptly drops the existing
> connection to the server and immediately requests the same page again.
>
> Well, this can cause problems on the server. For example, if the JSP page
> takes a non-trivial amount of time to render itself, then the socket write
> error will almost always occur since the 'peer' (IE5 in the case) always
> abruptly terminates the first connection to start the second. If the first
> JSP page request had time to open a database connection (before the second
> page request yanked the rug), then the socket write error may also interrupt
> the JSP's ability to execute enough logic to get to close the database
> connection at the bottom of the page. This tends to leave database
> connections hanging until they timeout.
>
> In my case, I was using a frameset which contained four JSPs--each of which
> emitted XML. In this case, each time I pressed F5, I saw four complete sets
> of "Socket Write Error" tracedumps along with stranding four different
> database connections. Imagine this problem in a scenario where hundreds or
> even thousands of customers were requesting updates to this frameset. There
> are two painpoints. First is the penalty of forcing the server to deal with
> needless exception handling four times per reload action (a performance
> penalty associated with dumping the stacktrace to the log file). Second are
> the resources held in limbo by stranded database connections (which looks
> like a big memory leak).
>
> My workaround is to avoid sending a pure XML page to IE5. Instead I send the
> XML data in an XML data island and use JavaScript to do the transformation.
> [Sample code follows] IE5 is still doing the transformation but since we're
> sending a real HTML file with embedded XML, instead of a real XML file, we
> don't have IE5 requesting every page twice.
>
> I would prefer to be sending pure XML/XSL to the browsers that can handle
> it. But even when/if this problem is fixed by MS, we still have to
> accommodate the millions of IE5 installations that don't have the patch. So
> this workaround is likely to stay online for a long time in my apps.
>
> I guess you could say that instead of fixing the problem, I'm avoiding the
> situation that leads to the problem in the first place.
>
> Cheers,
> Jeff
>
> <HTML>
> <HEAD>
> <XML id="xslTransform"
> src="http://<%=request.getServerName()%>/Whatever/Style/ClassData.xsl"></XML
> >
> <XML id="xmlData">
> <root>
> <!-- This JSP file emits the pure XML data for this page -->
> <jsp:include page="ClassData.jsp" flush="true" />
> </root>
> </XML>
> <script language="JavaScript">
> function doInitPage()
> {
> oData = xmlData.XMLDocument;
> document.all("InsertHere").innerHTML =
> oData.transformNode(xslTransform.XMLDocument);
> }
> </script>
> <link REL="STYLESHEET" TYPE="text/css"
>
> HREF="http://<%=request.getServerName()%>/Whatever/Style/ClassResources.css"
> />
> </HEAD>
> <body onload="doInitPage()" CLASS="NormalText" bgcolor="white" topmargin="0"
> bottommargin="0" leftmargin="0" rightmargin="0">
> <SPAN ID="InsertHere"></SPAN>
> </BODY>
> </HTML>
>
> Another variation is to have the JS actually replace the entire BODY section
> of the page. This would let the XSL file have complete control over the
> attributes of the Body tag. In my case, this wasn't necessary.
>
