tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34526] - Truncated content in decompressed requests from mod_deflate
Date Sat, 09 Jul 2005 04:08:18 GMT
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=34526>.
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=34526


mike_bos@mail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |




------- Additional Comments From mike_bos@mail.com  2005-07-09 06:08 -------
The client sends correct Content-Length equal to the compressed request size,
that's what it's supposed to be per HTTP 1.1, and I don't see where the client
has a problem here. Apache correctly reads the request, and mod_deflate
correctly decompresses it, only the servlet receives truncated content. Where
does the servlet spec imply that behaviour? The original Content-Length header
value cannot be trusted after passing through HTTP Server, specifically because
filters like mod_deflate may render it invalid.

Setting Content-Length to -1 might work as a workaround, but my point was that
it should also work with a correct positive Content-Length.

If I don't use mod_deflate's decompression and decompress with a servlet filter
instead, the servlet gets complete content, while the Content-Length header of
course remains with the original value, which is functionality-wise, but I would
much rather use mod_deflate's decompression for scalability and load
distribution reasons, and mod_deflate is likely faster than GZIPInputStream.

I initially thought it might be a mod_deflate's problem, but an HTTP Server
person (André Malo) said he is certain it should be fixed in mod_jk. I suppose
he implied that instead of trusting Content-Length, there is another more
reliable way to determine end of request stream from Apache. Please refer to the
HTTP Server bug linked in the original description.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message