IE 6 causes broken pipe exception
Here's a followup to: Subject: DefaultServlet throws a LOT of broken pipe exceptions on mp3s. --- I found the cause of my java.io.IOException Broken pipe errors. IE 6 is sending two GET requests for each .mp3 file. I haven't tested the behavior on IE 5.x or other plugin-handled mime types. The first GET sets the request header: user-agent = contype and is a Microsoft (ie, non-standard) attempt at data-sniffing intended to get just the header information. Tomcat 4.x starts sending the content data, but IE resets/drops the connection after 30-50k (100-500 ms), generating a Broken pipe exception. IE then sends a second request for the content using: user-agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) which completes. [see Microsoft Knowledge Base Articles: KB 293792, KB 254337, KB 310388. Note: KB 310388 describes a fix for multiple posts in IE 6 SP1 (service pack 1). Tests from an IE 6 SP1 client however still demonstrate the multiple GETs. I'm still trying to determine if the broken pipe GET is the cause of the unreliable caching behaving I'm seeing in IE 6 (symptom: IE 6 clients are downloading about 10x vs. Netscape/Safari clients; few if any 304 responses). --- So, two questions for the karmically kind: 1) Any bright ideas on a workaround for the user-agent: contype GET? At present it's double-banging my server for 100-200k files. Is there a context level mechanism for filtering, ie, blocking, requests based on headers? 2) Is this more properly a development issue? I see workarounds in the 4.1.27 and 5.x source to ignore Broken pipe exceptions and the multiple GET is apparently rooted in kludges from browser 4.x days -- but I got no hits for user-agent contype in a google of the tomcat archives. Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE 6 causes broken pipe exception
Hello Chris! CR IE 6 is sending two GET requests for each .mp3 file. I haven't tested the CR behavior on IE 5.x or other plugin-handled mime types. CR The first GET sets the request header: CR user-agent = contype CR and is a Microsoft (ie, non-standard) attempt at data-sniffing intended to CR get just the header information. Tomcat 4.x starts sending the content data, CR but IE resets/drops the connection after 30-50k (100-500 ms), generating a CR Broken pipe exception. CR IE then sends a second request for the content using: CR user-agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) CR which completes. CR [see Microsoft Knowledge Base Articles: KB 293792, KB 254337, KB 310388. CR Note: KB 310388 describes a fix for multiple posts in IE 6 SP1 (service pack CR 1). Tests from an IE 6 SP1 client however still demonstrate the multiple CR GETs. CR I'm still trying to determine if the broken pipe GET is the cause of the CR unreliable caching behaving I'm seeing in IE 6 (symptom: IE 6 clients are CR downloading about 10x vs. Netscape/Safari clients; few if any 304 CR responses). CR --- CR So, two questions for the karmically kind: CR 1) Any bright ideas on a workaround for the user-agent: contype GET? Yes, this can be handled by servicing your mp3 files via your own servlet. I could check for the user-agent: contype and then probably forwar the request or invoke RequestDispatcher. You may wrap the original request in the wrapper provided by the Servlet 2.3 API substituting the method GET with HEAD. (Do I remember it all correctly?) A more stratagic descision would be to build this into the Tomcat. I've entered an enahncement request to Tomcat bug database including your mail there. You may augment this enhancment request at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23294 CR At CR present it's double-banging my server for 100-200k files. Is there a context CR level mechanism for filtering, ie, blocking, requests based on headers? CR 2) Is this more properly a development issue? I see workarounds in the CR 4.1.27 and 5.x source to ignore Broken pipe exceptions This seems perfectly sane, the client may terminate connection for a multitude of reasons. CR and the multiple GET is apparently rooted in kludges from browser CR 4.x days -- Hmm, what did you mean, Chris? Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE 6 causes broken pipe exception
on 9/20/03 11:07 AM, Anton Tagunov wrote: Hello Chris! CR IE 6 is sending two GET requests for each .mp3 file. I haven't tested the CR behavior on IE 5.x or other plugin-handled mime types. [snip] CR So, two questions for the karmically kind: CR 1) Any bright ideas on a workaround for the user-agent: contype GET? Yes, this can be handled by servicing your mp3 files via your own servlet. I could check for the user-agent: contype and then probably forwar the request or invoke RequestDispatcher. You may wrap the original request in the wrapper provided by the Servlet 2.3 API substituting the method GET with HEAD. (Do I remember it all correctly?) Remapping the contype onto a HEAD seems like a good solution. A more stratagic descision would be to build this into the Tomcat. I've entered an enahncement request to Tomcat bug database including your mail there. You may augment this enhancment request at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23294 Thanks. I'll have a look. CR At CR present it's double-banging my server for 100-200k files. Is there a context CR level mechanism for filtering, ie, blocking, requests based on headers? CR 2) Is this more properly a development issue? I see workarounds in the CR 4.1.27 and 5.x source to ignore Broken pipe exceptions This seems perfectly sane, the client may terminate connection for a multitude of reasons. CR and the multiple GET is apparently rooted in kludges from browser CR 4.x days -- Hmm, what did you mean, Chris? The contype GET has its origins in the days when servers had inconsistent support for the HEAD method and continues to pop up under various guises in IE 4, 5 + 6. So the behaviour has been around for a long, long time. I'm wildly speculating that the workarounds to suppress broken pipe exceptions might be, at least in part, motivated by the excess of broken pipes caused by IE's data-sniffing technique. cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
