You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-auto@ws.apache.org by "Balázs Póka (JIRA)" <xm...@ws.apache.org> on 2008/10/24 13:35:45 UTC

[jira] Updated: (XMLRPC-153) content-length header incorrect when using gzip

     [ https://issues.apache.org/jira/browse/XMLRPC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Balázs Póka updated XMLRPC-153:
-------------------------------

    Attachment: patch.txt

If I'm not mistaken, the old email thread this issue was being discussed on was initiated by me. I continued to pursue the issue at that time, but got no reply to my last one or two messages. Now I've made a patch which fixes this problem since I ran into it again.

> 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.