You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Chris Rolfe <sp...@telus.net> on 2003/09/20 11:01:26 UTC
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
Re: IE 6 causes broken pipe exception
Posted by Chris Rolfe <sp...@telus.net>.
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
Re: IE 6 causes broken pipe exception
Posted by Chris Rolfe <sp...@telus.net>.
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: IE 6 causes broken pipe exception
Posted by Anton Tagunov <at...@mail.cnt.ru>.
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
Re: IE 6 causes broken pipe exception
Posted by Anton Tagunov <at...@mail.cnt.ru>.
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org