Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.0, 3.1
-
None
-
None
-
None
-
UNIX (FC3), Sun JDK1.5.0_10
Description
When doing some testing using the ws-xmlrpc client libraries I ran across a bug in its calculation of the content-length HTTP header when using gzip compression but not HTTP chunked transfer. The client incorrectly sets the content-length to the length of the uncompressed data, rather than the compressed data it sends. This happens using both 3.0 and 3.1 client libraries.
I see some activity on ws-xmlrpc-dev from September 2007 but no mention of any resolution. I did a quick bug search and found nothing - my apologies if this is already being tracked somewhere else and I missed it.
From the mail thread, a link to the relevant part of the HTTP spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13