Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Message-ID: <24014203.1179221836577.JavaMail.jira@brutus>
Date: Tue, 15 May 2007 02:37:16 -0700 (PDT)
From: "Mirko Friedenhagen (JIRA)" <jira@apache.org>
To: httpcomponents-dev@jakarta.apache.org
Subject: [jira] Commented: (HTTPCLIENT-651) Inconsistent, order dependant
 behaviour in HttpMethodBase.getResponse*
In-Reply-To: <385944.1179219436400.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495923 ] 

Mirko Friedenhagen commented on HTTPCLIENT-651:
-----------------------------------------------

Again thanks for the quick answer. I did not understand that you wanted to fix the documentation for 3.1, which is of course the only possibility without breaking everyones code.

Best Regards
Mirko

> Inconsistent, order dependant behaviour in HttpMethodBase.getResponse*
> ----------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-651
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-651
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>    Affects Versions: 3.1 RC1
>            Reporter: Mirko Friedenhagen
>            Priority: Minor
>             Fix For: 3.1 Final
>
>
> `getReponseBodyAsString` is storing the body  and may therefore provide a valid result if the code is requesting the body as stream afterwards. If you switch the order and first call getResponseBodyAsStream and afterwards try to `getReponseBodyAsString`, the result will be `null`.
> I wrote a unittest which hopefully describes the IMHO confusing behaviour:
>     public void testHttpClientBodyVsStream() throws HttpException, IOException {
>         final HttpClient httpClient = new HttpClient();
>         final GetMethod getMethod = new GetMethod("http://www.heise.de/");
>         final String bodyFromStream;
>         final String body;
>         try {
>             httpClient.executeMethod(getMethod);
>             body = getMethod.getResponseBodyAsString();
>             bodyFromStream = IOUtils.toString(getMethod
>                     .getResponseBodyAsStream());
>         } finally {
>             getMethod.releaseConnection();
>         }
>         assertEquals(body, bodyFromStream);
>     }
>     
>     public void testHttpClientStreamVsBody() throws HttpException, IOException {
>         final HttpClient httpClient = new HttpClient();
>         final GetMethod getMethod = new GetMethod("http://www.heise.de/");
>         final String bodyFromStream;
>         final String body;
>         try {
>             httpClient.executeMethod(getMethod);
>             bodyFromStream = IOUtils.toString(getMethod
>                     .getResponseBodyAsStream());
>             body = getMethod.getResponseBodyAsString();
>         } finally {
>             getMethod.releaseConnection();
>         }
>         // ** This will fail **
>         assertEquals(body, bodyFromStream);
>     }
> Searching http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodBase.java I understand the outcome, but this is confusing.
> I would expect the body data to be gone after calling one of the getResponse*-Methods and calling them again not to return null but even to throw an IllegalStateException. I would not store the body at all in the method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org