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]
