DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23294>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23294 Handle IE 6.0 GET user-agent: contype as HEAD Summary: Handle IE 6.0 GET user-agent: contype as HEAD Product: Tomcat 5 Version: 5.0.0 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Chris Rolfe <[EMAIL PROTECTED]> reports that IE 6.0 uses GET user-agent: contype insteat of HEAD He correctly complains that this causes extraneous load on the server and bandwidth consumption. If his report is correct Tomcat could sumulate a HEAD request (although I'm in doubt what would be best to supply instead of user-agent in such a case: probably omit this header or, as we know it's a IE, probably generate smth?) if user-agent is contype? Here's the original message by Chris Rolfe <[EMAIL PROTECTED]> 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]
