You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2004/03/17 20:23:50 UTC
DO NOT REPLY [Bug 26662] -
ClassCastException in GzipOutputFilter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=26662>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=26662
ClassCastException in GzipOutputFilter
------- Additional Comments From jakarta@trollingers.com 2004-03-17 19:23 -------
I found what was causing the class cast exception. The maxKeepAliveRequests is
set to 100. If more than 100 requests are sent to that connection then the
Http11Processor.process() sets keepAlive to false (which is the correct
behavior) but when Http11Processor.processResponse() is called the following
code
1485 if (contentLength != -1) {
1486 response.getMimeHeaders().setValue("Content-Length")
1487 .setInt(contentLength);
1488 outputBuffer.addActiveFilter
1489 (outputFilters[Constants.IDENTITY_FILTER]);
1490 contentDelimitation = true;
1491 } else {
1492 if (entityBody && http11 && keepAlive) {
1493 outputBuffer.addActiveFilter
1494 (outputFilters[Constants.CHUNKED_FILTER]);
1495 contentDelimitation = true;
1496 response.addHeader("Transfer-Encoding", "chunked");
1497 }
1498 }
does not add a filter there for causing the compression filter to be the only
one added.
I am attaching a patch that checks to see if there are any filters added before
the compression filter is and if not added the identityFilter.
All line numbers and the patch are for 5.0.18
John
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org