WRT to explanation # 2, I've been able to reproduce this error with
Netscape, but only by forcing the issue (ie., pressing 'Reload' at critical
times which causes existing sockets to close and starts loading the page all
over again--even though the server may not be finished delivering the
previously requested deliverables.) My gut feeling is that IE closes the
socket in mid-delivery whereas Netscape closes the socket at a more
appropriate time.
I've also seen it in situations where client-side scripting was forcing a
redirect at a bad time. This is similar to the scenario described above
where I was forcing NS to create the error, only this time it's being done
programmatically. I encountered this in a frameset when a user selects a
link which invokes client-side scripting in one frame to force another frame
to redirect. If the user makes the selection before the target frame is
completely loaded (more specifically, when something like an image is not
completely loaded yet) then you'll see these errors.
Finally, I've seen this specifically using XML/XSL pages in IEv5.5. In this
case, I was using JSPs to produce the contents of both the XML and XSL. I
was doing all the recommended things including setting the contentType to
text/xml, etc. Every time IE viewed this page, I would get the socket write
error. I embedded the page in a frameset and found that I would get one
error for each frame displaying XML/XSL data. I then decided to set
contentType back to text/html, send the XML/XSL data as separate XML Data
Islands to be transformed in the browser using JavaScript. The problem went
away. I've concluded that when IE requests the page from the server, it
seems to default to expecting text/html in the pending response. When IE
realizes that the response is not what was originally expected, it seems to
abruptly close the socket and request the page all over again--this time
anticipating the correct contentType. However, this abrupt socket closure
always results in the socket write error. Clearly this explanation is
purely my rationalization, but the behavior is easy for anyone to observe.
Personally, I was resistant to tweaking the app server's error reporting to
only report FATAL errors. I really want to continue to recognize when
errors happen, even non-fatal ones--but I don't want bugs in browsers
cluttering the logs. At the time I was doing this work, I was building a
intranet-based web application where I could take liberties such as
declaring a limited set of supported browsers. This means I had the luxury
of sending the XML/XSL as XML Data Islands and doing the transformations at
the client with JavaScript.
Cheers,
Jeff
