You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hc.apache.org by bu...@apache.org on 2003/07/07 21:20:59 UTC

DO NOT REPLY [Bug 21378] New: - Transfer-Encoding: identity not supported + possible patch

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21378

Transfer-Encoding: identity not supported + possible patch

           Summary: Transfer-Encoding: identity not supported + possible
                    patch
           Product: Commons
           Version: 2.0 Beta 2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: HttpClient
        AssignedTo: commons-httpclient-dev@jakarta.apache.org
        ReportedBy: brentbeardsley@yahoo.com


In HttpMethodBase.readResponseBody only chunked transfer encoding is 
supported.  Some proxy servers like Privoxy, etc send a Transfer-Encoding: 
identity header and HttpClient fails quietly and returns a null result input 
stream.  At line 2037 in HttpMethodBase.java revision 1.160 I inserted the 
following two lines and it appeared to work fine:

} else if ("identity".equalsIgnoreCase(transferEncodingHeader.getValue())) {
   result = is;

I think it should at least throw an exception or do something when it 
encounters an unsupported Transfer-Encoding instead of returning a null input 
stream.