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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
