[
https://issues.apache.org/jira/browse/XMLRPC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642481#action_12642481
]
Andy Meyer commented on XMLRPC-153:
-----------------------------------
The content-length should definitely reflect the actual length of the message
sent over the wire, ie the content after compression is applied. Without it the
HTTP protocol can't decode message boundaries over a persistent connection when
not using chunked transfer coding.
This has also bitten other projects, see eg:
http://bugs.php.net/bug.php?id=24083
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html, the note about not
trusting content-length - in that case the value of the content-length header
is left alone and reflects the length of the compressed content.
> content-length header incorrect when using gzip
> -----------------------------------------------
>
> Key: XMLRPC-153
> URL: https://issues.apache.org/jira/browse/XMLRPC-153
> Project: XML-RPC
> Issue Type: Bug
> Affects Versions: 3.0, 3.1
> Environment: UNIX (FC3), Sun JDK1.5.0_10
> Reporter: Andy Meyer
> Attachments: patch.txt
>
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
