[jira] [Commented] (HTTPCORE-459) Make request available to ResponseHandlers
[ https://issues.apache.org/jira/browse/HTTPCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16054018#comment-16054018 ] Tobias Oberlies commented on HTTPCORE-459: -- Oleg, why do you consider this "Not a problem"? > Make request available to ResponseHandlers > -- > > Key: HTTPCORE-459 > URL: https://issues.apache.org/jira/browse/HTTPCORE-459 > Project: HttpComponents HttpCore > Issue Type: Improvement >Affects Versions: 5.0-alpha3 >Reporter: Tobias Oberlies > > We use HttpClients for a system test of a REST API. We are using > ResponseHandlers to directly convert the response entity to a data structure > that is suitable for assertions. > This works very well, except for the occasional case where the system under > test responds with an unexpected status code. In this case, the response > handler throws an exception. For a good error message, it would be useful to > also include the request URL. However the request object is not available in > the ResponseHandler.handleResponse method. > So this is a request to also make the HttpRequest object available in the > ResponseHandler.handleResponse method. This could be done by adding a getter > in the HttpResponse class, or by creating a new interface (e.g. > HttpResponseHandler2) with a two-parameter handleResponse method. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1757) Make request available to ResponseHandlers
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385605#comment-15385605
]
Tobias Oberlies commented on HTTPCLIENT-1757:
-
Is there an attribute of the {{HttpContext}} that provides the current
{{HttpRequest}}?
> Make request available to ResponseHandlers
> --
>
> Key: HTTPCLIENT-1757
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1757
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
>Affects Versions: 4.5.2
>Reporter: Tobias Oberlies
> Fix For: 5.0 Alpha2
>
>
> We use HttpClients for a system test of a REST API. We are using
> ResponseHandlers to directly convert the response entity to a data structure
> that is suitable for assertions.
> This works very well, except for the occasional case where the system under
> test responds with an unexpected status code. In this case, the response
> handler throws an exception. For a good error message, it would be useful to
> also include the request URL. However the request object is not available in
> the ResponseHandler.handleResponse method.
> So this is a request to also make the HttpRequest object available in the
> ResponseHandler.handleResponse method. This could be done by adding a getter
> in the HttpResponse class, or by creating a new interface (e.g.
> HttpResponseHandler2) with a two-parameter handleResponse method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1757) Make request available to ResponseHandlers
Tobias Oberlies created HTTPCLIENT-1757: --- Summary: Make request available to ResponseHandlers Key: HTTPCLIENT-1757 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1757 Project: HttpComponents HttpClient Issue Type: Improvement Components: HttpClient Affects Versions: 4.5.2 Reporter: Tobias Oberlies We use HttpClients for a system test of a REST API. We are using ResponseHandlers to directly convert the response entity to a data structure that is suitable for assertions. This works very well, except for the occasional case where the system under test responds with an unexpected status code. In this case, the response handler throws an exception. For a good error message, it would be useful to also include the request URL. However the request object is not available in the ResponseHandler.handleResponse method. So this is a request to also make the HttpRequest object available in the ResponseHandler.handleResponse method. This could be done by adding a getter in the HttpResponse class, or by creating a new interface (e.g. HttpResponseHandler2) with a two-parameter handleResponse method. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1188) HTTP client does not monitor connection for error status while sending request body
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15256448#comment-15256448
]
Tobias Oberlies commented on HTTPCLIENT-1188:
-
bq. If for whatever reason you cannot use the 'expect-continue' handshaking to
avoid this problem, ...
This is e.g. the case if the server is a Tomcat: see
https://bz.apache.org/bugzilla/show_bug.cgi?id=57661
> HTTP client does not monitor connection for error status while sending
> request body
> ---
>
> Key: HTTPCLIENT-1188
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1188
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
>Affects Versions: 4.1.3
>Reporter: Benjamin Bentmann
>
> Quoting from http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2:
> bq. An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the
> network connection for an error status while it is transmitting the request.
> If the client sees an error status, it SHOULD immediately cease transmitting
> the body. If the body is being sent using a "chunked" encoding (section 3.6),
> a zero length chunk and empty trailer MAY be used to prematurely mark the end
> of the message. If the body was preceded by a Content-Length header, the
> client MUST close the connection.
> This is apparently not the case with the HttpClient. While uploading large
> files (tens of MBs) whose transfer takes notable time (~ 30 sec) we observed
> the following exceptions (the variation in detail msg are either due to Java
> version or OS):
> {noformat}
> java.net.SocketException: Broken pipe
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(OutputRecord.java:297)
> at com.sun.net.ssl.internal.ssl.OutputRecord.write(OutputRecord.java:286)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:743)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:731)
> at
> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
> at
> org.apache.http.impl.io.AbstractSessionOutputBuffer.write(AbstractSessionOutputBuffer.java:153)
> at
> org.apache.http.impl.io.ContentLengthOutputStream.write(ContentLengthOutputStream.java:114)
> at org.apache.http.entity.FileEntity.writeTo(FileEntity.java:75)
> at
> org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:96)
> at
> org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
> at
> org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:120)
> at
> org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:264)
> at
> org.apache.http.impl.conn.AbstractClientConnAdapter.sendRequestEntity(AbstractClientConnAdapter.java:224)
> at
> org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:255)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:647)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:464)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>
> java.net.SocketException: Connection reset by peer: socket write error
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> com.sun.net.ssl.internal.ssl.OutputRecord.writeBuffer(OutputRecord.java:297)
> at com.sun.net.ssl.internal.ssl.OutputRecord.write(OutputRecord.java:286)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:748)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:736)
> at
> com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:89)
> at
> org.apache.http.impl.io.AbstractSessionOutputBuffer.write(AbstractSessionOutputBuffer.java:153)
> at
> org.apache.http.impl.io.ContentLengthOutputStream.write(ContentLengthOutputStream.java:114)
> at org.apache.http.entity.FileEntity.writeTo(FileEntity.java:75)
> at
> org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:96)
> at
>
[jira] [Commented] (HTTPCLIENT-1279) NullPointerException (apparently) when authenticating
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225914#comment-15225914
]
Tobias Oberlies commented on HTTPCLIENT-1279:
-
The stacktrace from a 4.1.3 httpclient in this case is
{noformat}
java.lang.NullPointerException
at
org.apache.http.impl.client.DefaultRequestDirector.updateAuthState(DefaultRequestDirector.java:1211)
at
org.apache.http.impl.client.DefaultRequestDirector.handleResponse(DefaultRequestDirector.java:1131)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:492)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
{noformat}
I searched for this bug but had a hard time to find it because the stack trace
was missing.
> NullPointerException (apparently) when authenticating
> -
>
> Key: HTTPCLIENT-1279
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1279
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
>Affects Versions: 4.2.2
>Reporter: Sebastiano Vigna
> Fix For: 4.2.3
>
>
> Run the following class. This is likely to be a badly configured server, but
> DefaultHttpClient should not in any case throw a NPE.
> import org.apache.http.client.ResponseHandler;
> import org.apache.http.client.HttpClient;
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.BasicResponseHandler;
> import org.apache.http.impl.client.DefaultHttpClient;
> public class Bug {
> public final static void main(String[] args) throws Exception {
> HttpClient httpclient = new DefaultHttpClient();
> HttpGet httpget = new
> HttpGet("http://www.gruppotirrenia.it/robots.txt;);
> httpclient.execute(httpget);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1688) ProxySelectorRoutePlanner doesn't handle IllegalStateException thrown by SchemeRegistry.getScheme
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952887#comment-14952887
]
Tobias Oberlies commented on HTTPCLIENT-1688:
-
I expected this answer, but I still wanted to make you aware of this
programming error.
In particular because the same problem may exist elsewhere. Could you check the
other callers of {{getScheme}} that they handle the exception case correctly?
Did you consider throwing a checked exception from {{getScheme}} instead?
> ProxySelectorRoutePlanner doesn't handle IllegalStateException thrown by
> SchemeRegistry.getScheme
> -
>
> Key: HTTPCLIENT-1688
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1688
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Tobias Oberlies
>
> Unlike e.g. the {{DefaultHttpRoutePlanner}}, the
> {{ProxySelectorRoutePlanner}} doesn't handle the {{IllegalStateException}}
> that is thrown by {{SchemeRegistry.getScheme}} when using an unknown scheme.
> This means that the {{IllegalStateException}} is thrown all the way to the
> caller, e.g. {{HttpClient.execute}}.
> I suppose that the exception should be handled and converted into one of the
> checked exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1688) ProxySelectorRoutePlanner doesn't handle IllegalStateException thrown by SchemeRegistry.getScheme
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952933#comment-14952933
]
Tobias Oberlies commented on HTTPCLIENT-1688:
-
Sorry, I didn't know that SchemeRegistry is also deprecated. Never mind then
> ProxySelectorRoutePlanner doesn't handle IllegalStateException thrown by
> SchemeRegistry.getScheme
> -
>
> Key: HTTPCLIENT-1688
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1688
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 4.5
>Reporter: Tobias Oberlies
>
> Unlike e.g. the {{DefaultHttpRoutePlanner}}, the
> {{ProxySelectorRoutePlanner}} doesn't handle the {{IllegalStateException}}
> that is thrown by {{SchemeRegistry.getScheme}} when using an unknown scheme.
> This means that the {{IllegalStateException}} is thrown all the way to the
> caller, e.g. {{HttpClient.execute}}.
> I suppose that the exception should be handled and converted into one of the
> checked exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1688) ProxySelectorRoutePlanner doesn't handle IllegalStateException thrown by SchemeRegistry.getScheme
Tobias Oberlies created HTTPCLIENT-1688:
---
Summary: ProxySelectorRoutePlanner doesn't handle
IllegalStateException thrown by SchemeRegistry.getScheme
Key: HTTPCLIENT-1688
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1688
Project: HttpComponents HttpClient
Issue Type: Bug
Affects Versions: 4.5
Reporter: Tobias Oberlies
Unlike e.g. the {{DefaultHttpRoutePlanner}}, the {{ProxySelectorRoutePlanner}}
doesn't handle the {{IllegalStateException}} that is thrown by
{{SchemeRegistry.getScheme}} when using an unknown scheme. This means that the
{{IllegalStateException}} is thrown all the way to the caller, e.g.
{{HttpClient.execute}}.
I suppose that the exception should be handled and converted into one of the
checked exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
