You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Mirko Friedenhagen (JIRA)" <ji...@apache.org> on 2007/05/15 10:57:16 UTC
[jira] Created: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Inconsistent, order dependant behaviour in HttpMethodBase.getResponse*
----------------------------------------------------------------------
Key: HTTPCLIENT-651
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-651
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Reporter: Mirko Friedenhagen
Priority: Minor
`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
[jira] Commented: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Mirko Friedenhagen (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ortwin Glück updated HTTPCLIENT-651:
------------------------------------
Fix Version/s: 3.1 Final
Issue Type: Improvement (was: Bug)
Affects Version/s: 3.1 RC1
We will improve the API doc.
I agree it's arguable if the response should be buffered at all in getResponseBodyAsString. Anyway, the buffered body is eligible for gc as soon as you release the reference to the method object.
> 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
[jira] Assigned: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ortwin Glück reassigned HTTPCLIENT-651:
---------------------------------------
Assignee: Ortwin Glück
> 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
> Assigned To: Ortwin Glück
> Priority: Minor
> Fix For: 3.1 Final
>
> Attachments: patch.txt
>
>
> `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
[jira] Resolved: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ortwin Glück resolved HTTPCLIENT-651.
-------------------------------------
Resolution: Fixed
Patch committed.
> 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
> Assigned To: Ortwin Glück
> Priority: Minor
> Fix For: 3.1 Final
>
> Attachments: patch.txt
>
>
> `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
[jira] Updated: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ortwin Glück updated HTTPCLIENT-651:
------------------------------------
Attachment: patch.txt
Improved API doc
> 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
>
> Attachments: patch.txt
>
>
> `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
[jira] Commented: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Mirko Friedenhagen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495915 ]
Mirko Friedenhagen commented on HTTPCLIENT-651:
-----------------------------------------------
Hello Oleg, hello Ortwin,
thanks for the quick answers :-)
Oleg, I looked in the trunk (see the link in my message, I do not find a branch for the 4.0 codeline) and I do not the think the behaviour has changed?!
Ortwin, IMO a new major version should fix an issue even if breaking some old code instead of describing a strange behaviour (this is of course better than doing nothing ;-)).
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
[jira] Commented: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495909 ]
Oleg Kalnichevski commented on HTTPCLIENT-651:
----------------------------------------------
Mirco,
The 'modality' of the response handling logic in HttpClient is a well know and a very old problem that dates back to the days of HttpClient 1.x. (I remember discussing the issue as early as year 2002). The problem has been resolved in HttpClient 4.0 codeline. I do not see a possibility for fixing the problem in HttpClient 3.x without taking a very high risk of breaking existing applications.
Oleg
> Inconsistent, order dependant behaviour in HttpMethodBase.getResponse*
> ----------------------------------------------------------------------
>
> Key: HTTPCLIENT-651
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-651
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Reporter: Mirko Friedenhagen
> Priority: Minor
>
> `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
[jira] Commented: (HTTPCLIENT-651) Inconsistent, order dependant
behaviour in HttpMethodBase.getResponse*
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495920 ]
Ortwin Glück commented on HTTPCLIENT-651:
-----------------------------------------
Mirko,
4.0 is under Http Components. See http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpclient/trunk/
As mentioned before, the next major release (4.0) has a modified behaviour. We are not going to change the behaviour in the minor release (3.1).
Ortwin
> 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