[jira] [Commented] (HTTPCORE-481) Early response suspends output even when response status is not error

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123488#comment-16123488
 ] 

ASF subversion and git services commented on HTTPCORE-481:
--

Commit f1cf502e89d5845b60e1d8573e9e8fe07e306644 in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=f1cf502 ]

HTTPCORE-481: async request executor to treat non-error (status >= 200 and 
status < 400) out of sequence responses as valid


> Early response suspends output even when response status is not error
> -
>
> Key: HTTPCORE-481
> URL: https://issues.apache.org/jira/browse/HTTPCORE-481
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.5
>Reporter: Tuomas Kiviaho
>Assignee: Oleg Kalnichevski
> Fix For: 4.4.7
>
>
> I have a {{text/event-stream}} response where status code 200 is sent 
> immediately back even when there is still request body streaming in process. 
> This works well with Jetty client but for some reason I could only receive 
> the first full buffer at server side when switching over to HttpAsyncClient. 
> The only visible notion that something went wrong was Jetty doing an idle 
> timeout cleanup. Luckily there is a notion of connection state which got 
> invalidated when response was received but only when request body streaming 
> was still in progress.
> I found out via this link 
> https://stackoverflow.com/questions/14250991/is-it-acceptable-for-a-server-to-send-a-http-response-before-the-entire-request
>  that probably the reason behind the behavior is to prevent flooding the 
> server in case of an error.
> {quote}
> 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.
> {quote}
> Below is a patch that currently functions as a work-a-round for me. I'd still 
> prefer the current behavior in case of unauthorized authentication etc. 
> because the request body can be quite large.
> {code:title=org/apache/http/nio/protocol/HttpAsyncRequestExecutor.java:295}
>  } else if (state.getRequestState() == MessageState.BODY_STREAM) {
>  // Early response
> +if (statusCode >= 400) {
> conn.resetOutput();
> conn.suspendOutput();
> state.setRequestState(MessageState.COMPLETED);
> state.invalidate();
> +}
>  }
> {code}



--
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-1858) Very high GC pressure due to wire logging

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1858:
-

Commit 71271233909bac9ff9aaa677fc15fb0160462647 in httpcomponents-client's 
branch refs/heads/HTTPCLIENT-1858 from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=7127123 
]

[HTTPCLIENT-1858] Simplify and no longer use a system property to
override default max size.

> Very high GC pressure due to wire logging
> -
>
> Key: HTTPCLIENT-1858
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1858
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Arya Ketan
>Priority: Minor
>  Labels: performance
> Attachments: Screen Shot 2017-06-21 at 1.11.46 pm.png
>
>
> While running performance tests, I am seeing very high GC pressure due to the 
> following code
> in Wire.java 
> {code:java}
> private void wire(final String header, final InputStream instream)
>   throws IOException {
> final StringBuilder buffer = new StringBuilder();
> int ch;
> while ((ch = instream.read()) != -1) {
> if (ch == 13) {
> buffer.append("[\\r]");
> } else if (ch == 10) {
> buffer.append("[\\n]\"");
> buffer.insert(0, "\"");
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> buffer.setLength(0);
> } else if ((ch < 32) || (ch > 127)) {
> buffer.append("[0x");
> buffer.append(Integer.toHexString(ch));
> buffer.append("]");
> } else {
> buffer.append((char) ch);
> }
> }
> if (buffer.length() > 0) {
> buffer.append('\"');
> buffer.insert(0, '\"');
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> }
> }
> {code}
> This is because, we are trying to expand Stringbuffer continously , thus 
> leading to lot of char[] garbage. 
> 2 suggestions for improvements
> a) we look into whether logging level is enabled and only then construct the 
> message
> b) efficiently construct log message.



--
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-1858) Alleviate GC pressure due to wire logging

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1858:
-

Commit 527dce78a7950509fc9e301f405a9da268b7006d in httpcomponents-client's 
branch refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=527dce7 
]

[HTTPCLIENT-1858] Clone some code from Log4j 2 to cache a StringBuilder in a 
ThreadLocal.


> Alleviate GC pressure due to wire logging
> -
>
> Key: HTTPCLIENT-1858
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1858
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Arya Ketan
>Priority: Minor
>  Labels: performance
> Fix For: 5.0 Alpha3
>
> Attachments: Screen Shot 2017-06-21 at 1.11.46 pm.png
>
>
> While running performance tests, I am seeing very high GC pressure due to the 
> following code
> in Wire.java 
> {code:java}
> private void wire(final String header, final InputStream instream)
>   throws IOException {
> final StringBuilder buffer = new StringBuilder();
> int ch;
> while ((ch = instream.read()) != -1) {
> if (ch == 13) {
> buffer.append("[\\r]");
> } else if (ch == 10) {
> buffer.append("[\\n]\"");
> buffer.insert(0, "\"");
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> buffer.setLength(0);
> } else if ((ch < 32) || (ch > 127)) {
> buffer.append("[0x");
> buffer.append(Integer.toHexString(ch));
> buffer.append("]");
> } else {
> buffer.append((char) ch);
> }
> }
> if (buffer.length() > 0) {
> buffer.append('\"');
> buffer.insert(0, '\"');
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> }
> }
> {code}
> This is because, we are trying to expand Stringbuffer continously , thus 
> leading to lot of char[] garbage. 
> 2 suggestions for improvements
> a) we look into whether logging level is enabled and only then construct the 
> message
> b) efficiently construct log message.



--
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-1858) Alleviate GC pressure due to wire logging

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1858:
-

Commit 9da9f2c273248036088b8cfca3d0bc01ae6a8505 in httpcomponents-client's 
branch refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=9da9f2c 
]

Squashed commit of the following:

commit 71271233909bac9ff9aaa677fc15fb0160462647
Author: Gary Gregory 
Date:   Wed Jul 12 18:21:11 2017 -0700

[HTTPCLIENT-1858] Simplify and no longer use a system property to 
override default max size.

commit 375808a3ab125c02dbfcc94add3a9bc1fb126b4a
Author: Gary Gregory 
Date:   Fri Jun 30 16:42:50 2017 -0700

[HTTPCLIENT-1858] Clone some code from Log4j 2 to cache a StringBuilder 
in a ThreadLocal. Some TODO comments to address configuration of the upper 
bound of the StringBuilder which is current done with a System property.


> Alleviate GC pressure due to wire logging
> -
>
> Key: HTTPCLIENT-1858
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1858
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Arya Ketan
>Priority: Minor
>  Labels: performance
> Fix For: 5.0 Alpha3
>
> Attachments: Screen Shot 2017-06-21 at 1.11.46 pm.png
>
>
> While running performance tests, I am seeing very high GC pressure due to the 
> following code
> in Wire.java 
> {code:java}
> private void wire(final String header, final InputStream instream)
>   throws IOException {
> final StringBuilder buffer = new StringBuilder();
> int ch;
> while ((ch = instream.read()) != -1) {
> if (ch == 13) {
> buffer.append("[\\r]");
> } else if (ch == 10) {
> buffer.append("[\\n]\"");
> buffer.insert(0, "\"");
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> buffer.setLength(0);
> } else if ((ch < 32) || (ch > 127)) {
> buffer.append("[0x");
> buffer.append(Integer.toHexString(ch));
> buffer.append("]");
> } else {
> buffer.append((char) ch);
> }
> }
> if (buffer.length() > 0) {
> buffer.append('\"');
> buffer.insert(0, '\"');
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> }
> }
> {code}
> This is because, we are trying to expand Stringbuffer continously , thus 
> leading to lot of char[] garbage. 
> 2 suggestions for improvements
> a) we look into whether logging level is enabled and only then construct the 
> message
> b) efficiently construct log message.



--
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-1858) Alleviate GC pressure due to wire logging

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1858:
-

Commit 9da9f2c273248036088b8cfca3d0bc01ae6a8505 in httpcomponents-client's 
branch refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=9da9f2c 
]

Squashed commit of the following:

commit 71271233909bac9ff9aaa677fc15fb0160462647
Author: Gary Gregory 
Date:   Wed Jul 12 18:21:11 2017 -0700

[HTTPCLIENT-1858] Simplify and no longer use a system property to 
override default max size.

commit 375808a3ab125c02dbfcc94add3a9bc1fb126b4a
Author: Gary Gregory 
Date:   Fri Jun 30 16:42:50 2017 -0700

[HTTPCLIENT-1858] Clone some code from Log4j 2 to cache a StringBuilder 
in a ThreadLocal. Some TODO comments to address configuration of the upper 
bound of the StringBuilder which is current done with a System property.


> Alleviate GC pressure due to wire logging
> -
>
> Key: HTTPCLIENT-1858
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1858
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Arya Ketan
>Priority: Minor
>  Labels: performance
> Fix For: 5.0 Alpha3
>
> Attachments: Screen Shot 2017-06-21 at 1.11.46 pm.png
>
>
> While running performance tests, I am seeing very high GC pressure due to the 
> following code
> in Wire.java 
> {code:java}
> private void wire(final String header, final InputStream instream)
>   throws IOException {
> final StringBuilder buffer = new StringBuilder();
> int ch;
> while ((ch = instream.read()) != -1) {
> if (ch == 13) {
> buffer.append("[\\r]");
> } else if (ch == 10) {
> buffer.append("[\\n]\"");
> buffer.insert(0, "\"");
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> buffer.setLength(0);
> } else if ((ch < 32) || (ch > 127)) {
> buffer.append("[0x");
> buffer.append(Integer.toHexString(ch));
> buffer.append("]");
> } else {
> buffer.append((char) ch);
> }
> }
> if (buffer.length() > 0) {
> buffer.append('\"');
> buffer.insert(0, '\"');
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> }
> }
> {code}
> This is because, we are trying to expand Stringbuffer continously , thus 
> leading to lot of char[] garbage. 
> 2 suggestions for improvements
> a) we look into whether logging level is enabled and only then construct the 
> message
> b) efficiently construct log message.



--
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-1858) Alleviate GC pressure due to wire logging

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1858:
-

Commit 888cefb7cd39cff379321096e1c2519d6adbe93c in httpcomponents-client's 
branch refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=888cefb 
]

[HTTPCLIENT-1858] Clone some code from Log4j 2 to cache a StringBuilder
in a ThreadLocal. Update to use the StringBuilder's capacity instead of
its length to measure upper bound.

> Alleviate GC pressure due to wire logging
> -
>
> Key: HTTPCLIENT-1858
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1858
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Arya Ketan
>Priority: Minor
>  Labels: performance
> Fix For: 5.0 Alpha3
>
> Attachments: Screen Shot 2017-06-21 at 1.11.46 pm.png
>
>
> While running performance tests, I am seeing very high GC pressure due to the 
> following code
> in Wire.java 
> {code:java}
> private void wire(final String header, final InputStream instream)
>   throws IOException {
> final StringBuilder buffer = new StringBuilder();
> int ch;
> while ((ch = instream.read()) != -1) {
> if (ch == 13) {
> buffer.append("[\\r]");
> } else if (ch == 10) {
> buffer.append("[\\n]\"");
> buffer.insert(0, "\"");
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> buffer.setLength(0);
> } else if ((ch < 32) || (ch > 127)) {
> buffer.append("[0x");
> buffer.append(Integer.toHexString(ch));
> buffer.append("]");
> } else {
> buffer.append((char) ch);
> }
> }
> if (buffer.length() > 0) {
> buffer.append('\"');
> buffer.insert(0, '\"');
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> }
> }
> {code}
> This is because, we are trying to expand Stringbuffer continously , thus 
> leading to lot of char[] garbage. 
> 2 suggestions for improvements
> a) we look into whether logging level is enabled and only then construct the 
> message
> b) efficiently construct log message.



--
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] (HTTPCORE-477) org.apache.hc.core5.util.TestTimeout two method(testToString,testFromString) fails due to Locale setting missing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084507#comment-16084507
 ] 

ASF subversion and git services commented on HTTPCORE-477:
--

Commit 294bc9cf077bee2fd53499b50de83730ff772286 in httpcomponents-core's branch 
refs/heads/master from [~onderson]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=294bc9c ]

HTTPCORE-477 - add missing Locale.ROOT settings, otherwise test may fail on 
different platforms


> org.apache.hc.core5.util.TestTimeout two method(testToString,testFromString) 
> fails due to Locale setting missing
> 
>
> Key: HTTPCORE-477
> URL: https://issues.apache.org/jira/browse/HTTPCORE-477
> Project: HttpComponents HttpCore
>  Issue Type: Test
>  Components: HttpCore
>Reporter: Önder Sezgin
>Priority: Minor
>
> on my sandbox, build fails due to missing Locale.ROOT setting



--
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-1858) Very high GC pressure due to wire logging

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1858:
-

Commit 375808a3ab125c02dbfcc94add3a9bc1fb126b4a in httpcomponents-client's 
branch refs/heads/HTTPCLIENT-1858 from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=375808a 
]

[HTTPCLIENT-1858] Clone some code from Log4j 2 to cache a StringBuilder
in a ThreadLocal. Some TODO comments to address configuration of the
upper bound of the StringBuilder which is current done with a System
property.

> Very high GC pressure due to wire logging
> -
>
> Key: HTTPCLIENT-1858
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1858
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Arya Ketan
>Priority: Minor
>  Labels: performance
> Attachments: Screen Shot 2017-06-21 at 1.11.46 pm.png
>
>
> While running performance tests, I am seeing very high GC pressure due to the 
> following code
> in Wire.java 
> {code:java}
> private void wire(final String header, final InputStream instream)
>   throws IOException {
> final StringBuilder buffer = new StringBuilder();
> int ch;
> while ((ch = instream.read()) != -1) {
> if (ch == 13) {
> buffer.append("[\\r]");
> } else if (ch == 10) {
> buffer.append("[\\n]\"");
> buffer.insert(0, "\"");
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> buffer.setLength(0);
> } else if ((ch < 32) || (ch > 127)) {
> buffer.append("[0x");
> buffer.append(Integer.toHexString(ch));
> buffer.append("]");
> } else {
> buffer.append((char) ch);
> }
> }
> if (buffer.length() > 0) {
> buffer.append('\"');
> buffer.insert(0, '\"');
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> }
> }
> {code}
> This is because, we are trying to expand Stringbuffer continously , thus 
> leading to lot of char[] garbage. 
> 2 suggestions for improvements
> a) we look into whether logging level is enabled and only then construct the 
> message
> b) efficiently construct log message.



--
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] (HTTPCORE-475) Occasional issues in handling "204 No Content"

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072742#comment-16072742
 ] 

ASF subversion and git services commented on HTTPCORE-475:
--

Commit 08339dcca2696da5176e89b4da6d9653886b151c in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=08339dc ]

HTTPCORE-475: Elemental Reverse Proxy example to handle stale outgoing 
connections more gracefully


> Occasional issues in handling "204 No Content"
> --
>
> Key: HTTPCORE-475
> URL: https://issues.apache.org/jira/browse/HTTPCORE-475
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: Examples, HttpCore
>Affects Versions: 4.4.6
> Environment: Windows, Java 8
>Reporter: M.S. Dousti
>Priority: Minor
> Attachments: without-proxy.png, with-proxy.png
>
>
> While testing {{ElementalReverseProxy}}, I noted that occasionally, some 
> requests fail. Digging further, it seems that the code has some difficulty in 
> handling POST requests whose responses have "204 No Content" status. The bug 
> is intermittent, so it is a bit tricky to reproduce. One way is to run the 
> proxy against [http://www.bing.com]. (Notice it's HTTP and not HTTPS). Here 
> are the steps:
> 1) Change line 274 of {{ElementalReverseProxy}} to further assist in 
> debugging, from:
> {code:java}
> System.err.println("I/O error: " + ex.getMessage());
> {code}
> to:
> {code:java}
> ex.printStackTrace(); System.exit(-1);
> {code}
> 2) Add the following lines to your {{hosts}} file ({{/etc/hosts}} in Linux, 
> and {{%SystemRoot%\System32\drivers\etc\hosts}} in Windows):
> {code:none}
> 127.0.0.1 bing.com
> 127.0.0.1 www.bing.com
> {code}
> 3) Run {{ElementalReverseProxy}} against one of Bing's IP addresses. I used 
> {{204.79.197.200}}.
> 4) Navigate your browser to {{http://www.bing.com:}}, and watch the 
> output of 
> {{ElementalReverseProxy}}. Here's a sample run:
> {noformat}
> Listening on port 
> Incoming connection from /127.0.0.1
> Outgoing connection to /204.79.197.200
> New connection thread
> >> Request URI: /
> << Response: HTTP/1.1 200 OK
> Incoming connection from /127.0.0.1
> Outgoing connection to /204.79.197.200
> Incoming connection from /127.0.0.1
> New connection thread
> >> Request URI: 
> >> /fd/ls/l?IG=3C1FD9BC348B419DAF07D5D09D13=3ED5D1926AB96D71082FDB206BCB6CA6=Event.CPT={%22pp%22:{%22S%22:%22L%22,%22FC%22:-1,%22BC%22:-1,%22SE%22:-1,%22TC%22:-1,%22H%22:116,%22BP%22:134,%22CT%22:169,%22IL%22:1},%22ad%22:[-1,-1,1600,770,1600,770,0]}=SERP=Bn2
> Outgoing connection to /204.79.197.200
> New connection thread
> >> Request URI: /fd/ls/lsp.aspx?
> Incoming connection from /127.0.0.1
> Outgoing connection to /204.79.197.200
> New connection thread
> Incoming connection from /127.0.0.1
> >> Request URI: 
> >> /notifications/render?bnptrigger=%7B%22PartnerId%22%3A%22HomePage%22%2C%22IID%22%3A%22SERP.2000%22%2C%22Attributes%22%3A%7B%22RawRequestURL%22%3A%22%2F%22%7D%7D=3C1FD9BC348B419DAF07D5D09D13=SERP.2000
> Outgoing connection to /204.79.197.200
> New connection thread
> Incoming connection from /127.0.0.1
> >> Request URI: /sa/8_01_0_00/HpbHeaderPopup.js
> << Response: HTTP/1.1 204 OK
> Outgoing connection to /204.79.197.200
> New connection thread
> >> Request URI: /sa/8_01_0_00/homepageImgViewer_c.js
> << Response: HTTP/1.1 200 OK
> << Response: HTTP/1.1 200 OK
> << Response: HTTP/1.1 200 OK
> >> Request URI: 
> >> /HPImageArchive.aspx?format=js=0=1=1498898493932=hp
> org.apache.http.NoHttpResponseException: The target server failed to 
> respondIncoming connection from /127.0.0.1
> at 
> org.apache.http.impl.io.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:131)
> at 
> org.apache.http.impl.io.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:53)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> ElementalReverseProxy$ProxyHandler.handle(ElementalReverseProxy.java:134)
> at 
> org.apache.http.protocol.HttpService.doService(HttpService.java:437)
> at 
> org.apache.http.protocol.HttpService.handleRequest(HttpService.java:342)
> at 
> ElementalReverseProxy$ProxyThread.run(ElementalReverseProxy.java:262)
> {noformat}
> I don't know whether the problem lies within {{ElementalReverseProxy}}, or 
> the way HC handles 

[jira] [Commented] (HTTPCLIENT-1865) DefaultServiceUnavailableRetryStrategy does not respect HttpEntity#isRepeatable

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1865:
-

Commit 7dfd236dc155e97c650c9da9b4b3f9234b3b2de9 in httpcomponents-client's 
branch refs/heads/4.5.x from [~tjcelaya]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=7dfd236 
]

[HTTPCLIENT-1865] DefaultServiceUnavailableRetryStrategy does not
respect HttpEntity#isRepeatable.

> DefaultServiceUnavailableRetryStrategy does not respect 
> HttpEntity#isRepeatable
> ---
>
> Key: HTTPCLIENT-1865
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1865
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
> Environment: Any environment
>Reporter: Tomas Celaya
> Attachments: 
> 0001-Only-retry-request-when-HttpEntity.isRepeatable-retu.patch, 
> 0002-ServiceUnavailableRetryExec-test-case-for-verifying-.patch
>
>
> The {{HttpEntity}} interface provides a method for indicating whether or not 
> an entity can be automatically retried. While investigating an issue with 
> corruption of encrypted uploads in the [java-manta 
> library|https://github.com/joyent/java-manta] I discovered that requests were 
> being automatically retried in the event of a 503 response from the server. 
> Stepping through the execution path led me to discover that 
> {{ServiceUnavailableRetryExec}} does not check the supplied {{HttpRequest}} 
> to determine whether or not it can be safely retried. We've implemented a fix 
> within java-manta in our subcclass of 
> {{DefaultServiceUnavailableRetryStrategy}} but this seems like it could bite 
> others as well so I thought it would merit a bug report.
> The included patch corrects this behavior. Checked that {{mvn verify}} 
> completes successfully. Please let me know if there are any questions or 
> other modifications that I need to make in order to contribute this patch.



--
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-1858) Alleviate GC pressure due to wire logging

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1858:
-

Commit f2146cab622b63ff69a005040635c14fed509e54 in httpcomponents-client's 
branch refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=f2146ca 
]

[HTTPCLIENT-1858] Clone some code from Log4j 2 to cache a StringBuilder
in a ThreadLocal. Update to use the StringBuilder's capacity instead of
its length to measure upper bound.

> Alleviate GC pressure due to wire logging
> -
>
> Key: HTTPCLIENT-1858
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1858
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Arya Ketan
>Priority: Minor
>  Labels: performance
> Fix For: 5.0 Alpha3
>
> Attachments: Screen Shot 2017-06-21 at 1.11.46 pm.png
>
>
> While running performance tests, I am seeing very high GC pressure due to the 
> following code
> in Wire.java 
> {code:java}
> private void wire(final String header, final InputStream instream)
>   throws IOException {
> final StringBuilder buffer = new StringBuilder();
> int ch;
> while ((ch = instream.read()) != -1) {
> if (ch == 13) {
> buffer.append("[\\r]");
> } else if (ch == 10) {
> buffer.append("[\\n]\"");
> buffer.insert(0, "\"");
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> buffer.setLength(0);
> } else if ((ch < 32) || (ch > 127)) {
> buffer.append("[0x");
> buffer.append(Integer.toHexString(ch));
> buffer.append("]");
> } else {
> buffer.append((char) ch);
> }
> }
> if (buffer.length() > 0) {
> buffer.append('\"');
> buffer.insert(0, '\"');
> buffer.insert(0, header);
> log.debug(id + " " + buffer.toString());
> }
> }
> {code}
> This is because, we are trying to expand Stringbuffer continously , thus 
> leading to lot of char[] garbage. 
> 2 suggestions for improvements
> a) we look into whether logging level is enabled and only then construct the 
> message
> b) efficiently construct log message.



--
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-1865) DefaultServiceUnavailableRetryStrategy does not respect HttpEntity#isRepeatable

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1865:
-

Commit 9efcba87302dc76fe31b33d685bca1fea34cf7f2 in httpcomponents-client's 
branch refs/heads/master from [~tjcelaya]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=9efcba8 
]

[HTTPCLIENT-1865] DefaultServiceUnavailableRetryStrategy does not
respect HttpEntity#isRepeatable.


> DefaultServiceUnavailableRetryStrategy does not respect 
> HttpEntity#isRepeatable
> ---
>
> Key: HTTPCLIENT-1865
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1865
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
> Environment: Any environment
>Reporter: Tomas Celaya
> Fix For: 4.5.4
>
> Attachments: 
> 0001-Only-retry-request-when-HttpEntity.isRepeatable-retu.patch, 
> 0002-ServiceUnavailableRetryExec-test-case-for-verifying-.patch
>
>
> The {{HttpEntity}} interface provides a method for indicating whether or not 
> an entity can be automatically retried. While investigating an issue with 
> corruption of encrypted uploads in the [java-manta 
> library|https://github.com/joyent/java-manta] I discovered that requests were 
> being automatically retried in the event of a 503 response from the server. 
> Stepping through the execution path led me to discover that 
> {{ServiceUnavailableRetryExec}} does not check the supplied {{HttpRequest}} 
> to determine whether or not it can be safely retried. We've implemented a fix 
> within java-manta in our subcclass of 
> {{DefaultServiceUnavailableRetryStrategy}} but this seems like it could bite 
> others as well so I thought it would merit a bug report.
> The included patch corrects this behavior. Checked that {{mvn verify}} 
> completes successfully. Please let me know if there are any questions or 
> other modifications that I need to make in order to contribute this patch.



--
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-1865) DefaultServiceUnavailableRetryStrategy does not respect HttpEntity#isRepeatable

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1865:
-

Commit 8ec17b68222b7907852badc7d9efa9ebdaa18bf9 in httpcomponents-client's 
branch refs/heads/4.6.x from [~tjcelaya]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=8ec17b6 
]

[HTTPCLIENT-1865] DefaultServiceUnavailableRetryStrategy does not
respect HttpEntity#isRepeatable.

> DefaultServiceUnavailableRetryStrategy does not respect 
> HttpEntity#isRepeatable
> ---
>
> Key: HTTPCLIENT-1865
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1865
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
> Environment: Any environment
>Reporter: Tomas Celaya
> Fix For: 4.5.4
>
> Attachments: 
> 0001-Only-retry-request-when-HttpEntity.isRepeatable-retu.patch, 
> 0002-ServiceUnavailableRetryExec-test-case-for-verifying-.patch
>
>
> The {{HttpEntity}} interface provides a method for indicating whether or not 
> an entity can be automatically retried. While investigating an issue with 
> corruption of encrypted uploads in the [java-manta 
> library|https://github.com/joyent/java-manta] I discovered that requests were 
> being automatically retried in the event of a 503 response from the server. 
> Stepping through the execution path led me to discover that 
> {{ServiceUnavailableRetryExec}} does not check the supplied {{HttpRequest}} 
> to determine whether or not it can be safely retried. We've implemented a fix 
> within java-manta in our subcclass of 
> {{DefaultServiceUnavailableRetryStrategy}} but this seems like it could bite 
> others as well so I thought it would merit a bug report.
> The included patch corrects this behavior. Checked that {{mvn verify}} 
> completes successfully. Please let me know if there are any questions or 
> other modifications that I need to make in order to contribute this patch.



--
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] (HTTPCORE-482) org.apache.http.nio.protocol.HttpAsyncService returns an empty response when a socket timeout is detected

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16129570#comment-16129570
 ] 

ASF subversion and git services commented on HTTPCORE-482:
--

Commit ac1dc48bc874bf9b856308430233f9e55df9256c in httpcomponents-core's branch 
refs/heads/HTTPCORE-482 from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=ac1dc48 ]

[HTTPCORE-482] org.apache.http.nio.protocol.HttpAsyncService does
returns an empty response when a socket timeout is detected

> org.apache.http.nio.protocol.HttpAsyncService returns an empty response when 
> a socket timeout is detected
> -
>
> Key: HTTPCORE-482
> URL: https://issues.apache.org/jira/browse/HTTPCORE-482
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.6
> Environment: org.apache.http.nio.protocol.HttpAsyncService does 
> returns an empty response when a socket timeout is detected
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.7
>
> Attachments: httpcomponents-core-4.4.x.patch
>
>
> org.apache.http.nio.protocol.HttpAsyncService does returns an empty response 
> when a socket timeout is detected.
> When a timeout occurs in an async proxy when an origin server takes too long 
> to reply, HttpAsyncService returns empty response.
> You can reproduce this issue with our async example {{NHttpReverseProxy}}:
> Start it with: http://postman-echo.com 
> Then run:
> {noformat}
> curl --verbose --max-time 1000 http://localhost:/delay/3
> {noformat}
> and you will get an EMPTY response from the server, no HTTP status code where 
> I would expect a 504 or 500.
> The proxy prints out:
> {noformat}
> Reverse proxy to http://postman-echo.com:80
> [client->proxy] connection open 127.0.0.1:<->127.0.0.1:61128
> [client->proxy] 0001 GET /delay/3 HTTP/1.1
> [client->proxy] 0001 request completed
> [proxy->origin] connection open 192.168.0.112:61130<->52.44.234.173:80
> [proxy->origin] 0001 GET /delay/3 HTTP/1.1
> [proxy->origin] 0001 request completed
> [client->proxy] connection closed 127.0.0.1:<->127.0.0.1:61128
> [client<-proxy] 0001 java.net.SocketTimeoutException
> [proxy->origin] connection released 192.168.0.112:61130<->52.44.234.173:80
> [proxy->origin] [total kept alive: 0; total allocated: 0 of 100]
> [proxy->origin] connection closed 192.168.0.112:61130<->52.44.234.173:80
> {noformat}
> Curl prints:
> {noformat}
> * STATE: INIT => CONNECT handle 0x600057930; line 1410 (connection #-5000)
> * Added connection 0. The cache now contains 1 members
> * STATE: CONNECT => WAITRESOLVE handle 0x600057930; line 1446 (connection #0)
> *   Trying ::1...
> * TCP_NODELAY set
> * STATE: WAITRESOLVE => WAITCONNECT handle 0x600057930; line 1527 (connection 
> #0)
> *   Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port  (#0)
> * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057930; line 1579 
> (connection #0)
> * Marked for [keep alive]: HTTP default
> * STATE: SENDPROTOCONNECT => DO handle 0x600057930; line 1597 (connection #0)
> > GET /delay/3 HTTP/1.1
> > Host: localhost:
> > User-Agent: curl/7.54.1
> > Accept: */*
> >
> * STATE: DO => DO_DONE handle 0x600057930; line 1676 (connection #0)
> * STATE: DO_DONE => WAITPERFORM handle 0x600057930; line 1801 (connection #0)
> * STATE: WAITPERFORM => PERFORM handle 0x600057930; line 1811 (connection #0)
> * STATE: PERFORM => DONE handle 0x600057930; line 1980 (connection #0)
> * multi_done
> * Empty reply from server
> * Connection #0 to host localhost left intact
> * Expire cleared
> curl: (52) Empty reply from server
> {noformat}
> I have a fix that returns a 504 GATEWAY_TIMEOUT when a socket timeout is 
> detected.
> Please see branch HTTPCORE-482 in git. Build passes with {{mvn clean 
> verify}}. I also attached the changes as a patch in 
> {{httpcomponents-core-4.4.x.patch}}.
> I have not created a unit test patch but the above scenario now works.



--
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] (HTTPCORE-390) Lock-less connection pools

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134441#comment-16134441
 ] 

ASF subversion and git services commented on HTTPCORE-390:
--

Commit 41d642f1ad9dd6e826708ef38095b5b3a6300753 in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=41d642f ]

HTTPCORE-390: Connection pool implementation with higher concurrency 
characteristics and lax total and per route max guarantees.


> Lock-less connection pools
> --
>
> Key: HTTPCORE-390
> URL: https://issues.apache.org/jira/browse/HTTPCORE-390
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Affects Versions: 4.3.2
>Reporter: Stephane Routhiau
>Assignee: Oleg Kalnichevski
>  Labels: concurrency, performance
> Fix For: 5.0
>
> Attachments: AbstractNIOConnPool.java, ConcurrentLinkedQueue.java, 
> contention on lease and release.png, DefaultConnectingIOReactor.java, 
> patch-performance nio pool.patch, RouteSpecificPool.java, 
> SessionRequestCallback.java
>
>
> AbstractNIOConnPool use a ReentrantLock for lease and release connection.
> We have noticed important contention when we try to use hundreds of 
> connexions to the same host, the lock is to vast.
> I managed to rework a part of the code so there is no more use of a 
> ReentrantLock, but use of ConcurrentHashMap and so on.
> The unit tests are ok and the load tests we have made on the patch version 
> are about 40 % faster under heavy load
> Please find attached patch file againt http-nio 4.3.2 and the modified 
> sources files of http-nio 4.3.2



--
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] (HTTPCORE-482) org.apache.http.nio.protocol.HttpAsyncService returns an empty response when a socket timeout is detected

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130459#comment-16130459
 ] 

ASF subversion and git services commented on HTTPCORE-482:
--

Commit a5f3bb9e989a232d864d986d7a1d2145032c59c6 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=a5f3bb9 ]

[HTTPCORE-482] org.apache.http.nio.protocol.HttpAsyncService does
returns an empty response when a socket timeout is detected

> org.apache.http.nio.protocol.HttpAsyncService returns an empty response when 
> a socket timeout is detected
> -
>
> Key: HTTPCORE-482
> URL: https://issues.apache.org/jira/browse/HTTPCORE-482
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.6
> Environment: org.apache.http.nio.protocol.HttpAsyncService does 
> returns an empty response when a socket timeout is detected
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.7
>
> Attachments: httpcomponents-core-4.4.x.patch
>
>
> org.apache.http.nio.protocol.HttpAsyncService does returns an empty response 
> when a socket timeout is detected.
> When a timeout occurs in an async proxy when an origin server takes too long 
> to reply, HttpAsyncService returns empty response.
> You can reproduce this issue with our async example {{NHttpReverseProxy}}:
> Start it with: http://postman-echo.com 
> Then run:
> {noformat}
> curl --verbose --max-time 1000 http://localhost:/delay/3
> {noformat}
> and you will get an EMPTY response from the server, no HTTP status code where 
> I would expect a 504 or 500.
> The proxy prints out:
> {noformat}
> Reverse proxy to http://postman-echo.com:80
> [client->proxy] connection open 127.0.0.1:<->127.0.0.1:61128
> [client->proxy] 0001 GET /delay/3 HTTP/1.1
> [client->proxy] 0001 request completed
> [proxy->origin] connection open 192.168.0.112:61130<->52.44.234.173:80
> [proxy->origin] 0001 GET /delay/3 HTTP/1.1
> [proxy->origin] 0001 request completed
> [client->proxy] connection closed 127.0.0.1:<->127.0.0.1:61128
> [client<-proxy] 0001 java.net.SocketTimeoutException
> [proxy->origin] connection released 192.168.0.112:61130<->52.44.234.173:80
> [proxy->origin] [total kept alive: 0; total allocated: 0 of 100]
> [proxy->origin] connection closed 192.168.0.112:61130<->52.44.234.173:80
> {noformat}
> Curl prints:
> {noformat}
> * STATE: INIT => CONNECT handle 0x600057930; line 1410 (connection #-5000)
> * Added connection 0. The cache now contains 1 members
> * STATE: CONNECT => WAITRESOLVE handle 0x600057930; line 1446 (connection #0)
> *   Trying ::1...
> * TCP_NODELAY set
> * STATE: WAITRESOLVE => WAITCONNECT handle 0x600057930; line 1527 (connection 
> #0)
> *   Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port  (#0)
> * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057930; line 1579 
> (connection #0)
> * Marked for [keep alive]: HTTP default
> * STATE: SENDPROTOCONNECT => DO handle 0x600057930; line 1597 (connection #0)
> > GET /delay/3 HTTP/1.1
> > Host: localhost:
> > User-Agent: curl/7.54.1
> > Accept: */*
> >
> * STATE: DO => DO_DONE handle 0x600057930; line 1676 (connection #0)
> * STATE: DO_DONE => WAITPERFORM handle 0x600057930; line 1801 (connection #0)
> * STATE: WAITPERFORM => PERFORM handle 0x600057930; line 1811 (connection #0)
> * STATE: PERFORM => DONE handle 0x600057930; line 1980 (connection #0)
> * multi_done
> * Empty reply from server
> * Connection #0 to host localhost left intact
> * Expire cleared
> curl: (52) Empty reply from server
> {noformat}
> I have a fix that returns a 504 GATEWAY_TIMEOUT when a socket timeout is 
> detected.
> Please see branch HTTPCORE-482 in git. Build passes with {{mvn clean 
> verify}}. I also attached the changes as a patch in 
> {{httpcomponents-core-4.4.x.patch}}.
> I have not created a unit test patch but the above scenario now works.



--
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] (HTTPCORE-473) ElementalReverseProxy does not properly handle POST requests

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062052#comment-16062052
 ] 

ASF subversion and git services commented on HTTPCORE-473:
--

Commit 3a4fe27afd894ac69514f51e57b6f6652fea4cab in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=3a4fe27 ]

HTTPCORE-473: fixed classic i/o reverse proxy example


> ElementalReverseProxy does not properly handle POST requests
> 
>
> Key: HTTPCORE-473
> URL: https://issues.apache.org/jira/browse/HTTPCORE-473
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: Examples
>Affects Versions: 4.4.6
> Environment: Windows 7, Java 8
>Reporter: M.S. Dousti
>Priority: Minor
>
> Dear Oleg et al.,
> I understand that {{ElementalReverseProxy}} is provided just as an example, 
> but it will be great if this example works properly, as it shows how the 
> underlying API must be used.
> Here's a simple setup that shows why {{ElementalReverseProxy}} fails to work 
> with POST request (and in fact, any requests including {{Content-Length}} or 
> {{Transfer-Content}} headers):
> # Let {{http://127.0.0.1:80}} denote the back-end server which we want to 
> proxy against, and assume the server hosts the file {{/index.html}}.
> # Run {{ElementalReverseProxy}} with default config against the back-end 
> server.
> Test the back-end server using {{wget}}:
> {code:none}
> wget http://127.0.0.1:80 --post-data="some data"
> --2017-06-24 11:52:30--  http://127.0.0.1/
> Connecting to 127.0.0.1:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 343 [text/html]
> Saving to: 'index.html'
> index.html  
> 100%[>] 343  --.-KB/s 
>in 0s
> 2017-06-24 11:52:30 (9.78 MB/s) - 'index.html' saved [343/343]
> {code}
> As you can see, it works just fine. Now try it with {{ElementalReverseProxy}}:
> {code:none}
> wget http://127.0.0.1: --post-data="some data"
> --2017-06-24 11:53:31--  http://127.0.0.1:/
> Connecting to 127.0.0.1:... connected.
> HTTP request sent, awaiting response... 400 Bad Request
> 2017-06-24 11:53:31 ERROR 400: Bad Request.
> {code}
> h3. Resolution
> {{ProxyThread}} executes {{httpservice.handleRequest}}, which in turn calls 
> {{processor.process(request, context)}}. This causes 
> {{RequestContent.process()}} to be executed, which throws an exception as it 
> finds that the request already contains the {{Content-Length}} header.
> One way to rectify this is to initialize {{inhttpproc}} with 
> {{RequestContent(true)}}, which overwrites the {{Content-Length}} header even 
> if it is present, without throwing an exception.
> Running {{wget}} again will now result in no error, but with one catch: 
> Notice the response misses the {{Content-Length}} header (this is evident 
> from {{Length: unspecified}} below):
> {code:none}
> wget http://127.0.0.1: --post-data="some data"
> --2017-06-24 12:09:25--  http://127.0.0.1:/
> Connecting to 127.0.0.1:... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/html]
> Saving to: 'index.html'
> index.html  [ <=> 
> ] 343  --.-KB/sin 0s
> 2017-06-24 12:09:25 (8.82 MB/s) - 'index.html' saved [343]
> {code}
> This is due to the line {{targetResponse.removeHeaders(HTTP.CONTENT_LEN)}} in 
> {{ProxyHandler#handle()}} method. Commenting this line will resolve the issue.
> In general, I don't get the {{ProxyHandler#handle()}} method: It is called by 
> {{HttpService#doService()}}, which in turn gets called just after the 
> following line:
> {code:java}
> this.processor.process(request, context);
> {code}
> So, it means that just after the above line applied mandatory HTTP headers, 
> {{ProxyHandler#handle()}} removes them all! Next, it tries to re-apply them:
> {code:java}
> this.httpexecutor.preProcess(request, this.httpproc, context);
> {code}
> But here, {{this.httpproc}} refers to {{outhttpproc}}, for which the 
> {{requestInterceptors}} instance is {{null}} effectively doing nothing.



--
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] (HTTPCORE-454) Add a Timeout class that extends TimeValue

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063774#comment-16063774
 ] 

ASF subversion and git services commented on HTTPCORE-454:
--

Commit d733e0ee9571286842e0c098df7c3044d2158d58 in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=d733e0e ]

HTTPCORE-454: use Timeout class to represent timeout values


> Add a Timeout class that extends TimeValue
> --
>
> Key: HTTPCORE-454
> URL: https://issues.apache.org/jira/browse/HTTPCORE-454
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 5.0
>
>
> Add a {{Timeout}} class that extends {{TimeValue}}. {{Timeout}} will validate 
> input so that you cannot define a negative timeout. A couple of handy 
> constants and methods will also be defined (like {{UNDEFINED}} and 
> {{DISABLED}}).



--
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] (HTTPCORE-454) Add a Timeout class that extends TimeValue

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062418#comment-16062418
 ] 

ASF subversion and git services commented on HTTPCORE-454:
--

Commit cfb878cf97d03b6365e66084cfcb0da8205dc0dc in httpcomponents-core's branch 
refs/heads/dev/HTTPCORE-454 from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=cfb878c ]

HTTPCORE-454: use Timeout class to represent timeout values


> Add a Timeout class that extends TimeValue
> --
>
> Key: HTTPCORE-454
> URL: https://issues.apache.org/jira/browse/HTTPCORE-454
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 5.0
>
>
> Add a {{Timeout}} class that extends {{TimeValue}}. {{Timeout}} will validate 
> input so that you cannot define a negative timeout. A couple of handy 
> constants and methods will also be defined (like {{UNDEFINED}} and 
> {{DISABLED}}).



--
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] (HTTPCORE-454) Add a Timeout class that extends TimeValue

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062631#comment-16062631
 ] 

ASF subversion and git services commented on HTTPCORE-454:
--

Commit 051a401fcd1b87e49fc07ff742b8cf794d082054 in httpcomponents-core's branch 
refs/heads/dev/HTTPCORE-454 from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=051a401 ]

HTTPCORE-454: Use #defaultsTo methods to choose a default value in case the 
given time value is null


> Add a Timeout class that extends TimeValue
> --
>
> Key: HTTPCORE-454
> URL: https://issues.apache.org/jira/browse/HTTPCORE-454
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 5.0
>
>
> Add a {{Timeout}} class that extends {{TimeValue}}. {{Timeout}} will validate 
> input so that you cannot define a negative timeout. A couple of handy 
> constants and methods will also be defined (like {{UNDEFINED}} and 
> {{DISABLED}}).



--
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-1859) FormBodyPartBuilder.java does not properly escape the name and filename subfields in the ContentDisposition header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1859:
-

Commit 004c8be08bc7f347348a28dd19147684916f9f54 in httpcomponents-client's 
branch refs/heads/HTTPCLIENT_1859 from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=004c8be 
]

HTTPCLIENT-1859: Encode header name, filename appropriately


> FormBodyPartBuilder.java does not properly escape the name and filename 
> subfields in the ContentDisposition header
> --
>
> Key: HTTPCLIENT-1859
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1859
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: Karl Wright
>Assignee: Oleg Kalnichevski
> Attachments: HTTPCLIENT-1859.patch, HTTPCLIENT-1859.patch
>
>
> The ContentDisposition header, used in multi-part forms, has a name and 
> filename subfield; these need to be escaped using unix-standard backslash 
> character stuffing, but FormBodyPartBuilder does not currently do this.  It 
> should.



--
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-1859) FormBodyPartBuilder.java does not properly escape the name and filename subfields in the ContentDisposition header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1859:
-

Commit f0c7a3448428fcd7e5b292bca8517c09bc71c3c6 in httpcomponents-client's 
branch refs/heads/4.6.x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=f0c7a34 
]

HTTPCLIENT-1859: Encode header name, filename appropriately


> FormBodyPartBuilder.java does not properly escape the name and filename 
> subfields in the ContentDisposition header
> --
>
> Key: HTTPCLIENT-1859
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1859
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: Karl Wright
>Assignee: Oleg Kalnichevski
> Attachments: HTTPCLIENT-1859.patch, HTTPCLIENT-1859.patch
>
>
> The ContentDisposition header, used in multi-part forms, has a name and 
> filename subfield; these need to be escaped using unix-standard backslash 
> character stuffing, but FormBodyPartBuilder does not currently do this.  It 
> should.



--
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-1859) FormBodyPartBuilder.java does not properly escape the name and filename subfields in the ContentDisposition header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1859:
-

Commit 6d583c7d8cc41a188a190218a6489541b79cf35a in httpcomponents-client's 
branch refs/heads/4.5.x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=6d583c7 
]

HTTPCLIENT-1859: Encode header name, filename appropriately


> FormBodyPartBuilder.java does not properly escape the name and filename 
> subfields in the ContentDisposition header
> --
>
> Key: HTTPCLIENT-1859
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1859
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: Karl Wright
>Assignee: Oleg Kalnichevski
> Attachments: HTTPCLIENT-1859.patch, HTTPCLIENT-1859.patch
>
>
> The ContentDisposition header, used in multi-part forms, has a name and 
> filename subfield; these need to be escaped using unix-standard backslash 
> character stuffing, but FormBodyPartBuilder does not currently do this.  It 
> should.



--
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] (HTTPCORE-472) incorrect "Maximum line length limit exceeded" detection is possible

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050475#comment-16050475
 ] 

ASF subversion and git services commented on HTTPCORE-472:
--

Commit 09d65b9b3e4aefe9c36b1a5ee6b8d6944e411302 in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=09d65b9 ]

HTTPCORE-472: Fixed problem with blocking message parsers incorrectly throwing 
"Maximum line length limit exceeded" exception in some corner cases


> incorrect "Maximum line length limit exceeded" detection is possible
> 
>
> Key: HTTPCORE-472
> URL: https://issues.apache.org/jira/browse/HTTPCORE-472
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 4.4.6
>Reporter: Artem Nakonechnyy
>Assignee: Oleg Kalnichevski
>
> the error is in 
> org.apache.http.impl.io.SessionInputBufferImpl#readLine(org.apache.http.util.CharArrayBuffer)
> {code}
> if (maxLineLen > 0) {
> final int currentLen = this.linebuffer.length()
> + (pos > 0 ? pos : this.bufferlen) - this.bufferpos;
> if (currentLen >= maxLineLen) {
> throw new MessageConstraintException("Maximum line length 
> limit exceeded");
> }
> }
> {code}
> If LF chanced to be at the beginning of the buffer, {{currentLen}} is 
> calculated incorrectly. It should be {{this.linebuffer.length() + pos - 
> this.bufferpos}}, so, effectively {{this.linebuffer.length() + 0 - 0}}.
> E.g. if maxLineLen=1, buffer.length=8192 (the default setting), a line is 
> 9000, then it doesn't fit the buffer, thus it's 1st part is read into 
> {{linebuffer}}, 2nd part is read into {{buffer}}. If the 9000 line's 
> terminating LF chances to be the 1st char of that buffer, and after that line 
> it follows more header data, say, exceeding 8192 bytes - then the code 
> calculates {{currentLen = linebuffer.length() + bufferlen - bufferpos = 9000+ 
> 8192 - 0}} > 1, while actual line length is just 9000.
> I think the fix is to replace {{(pos > 0 ? pos : this.bufferlen)}} to {{(pos 
> > -1 ? pos : this.bufferlen)}}



--
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] (HTTPCORE-472) incorrect "Maximum line length limit exceeded" detection is possible

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050361#comment-16050361
 ] 

ASF subversion and git services commented on HTTPCORE-472:
--

Commit 0877c288253c1e431eb2b59107d8a037d07a6d80 in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=0877c28 ]

HTTPCORE-472: Fixed problem with blocking message parsers incorrectly throwing 
"Maximum line length limit exceeded" exception in some corner cases


> incorrect "Maximum line length limit exceeded" detection is possible
> 
>
> Key: HTTPCORE-472
> URL: https://issues.apache.org/jira/browse/HTTPCORE-472
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 4.4.6
>Reporter: Artem Nakonechnyy
>Assignee: Oleg Kalnichevski
>
> the error is in 
> org.apache.http.impl.io.SessionInputBufferImpl#readLine(org.apache.http.util.CharArrayBuffer)
> {code}
> if (maxLineLen > 0) {
> final int currentLen = this.linebuffer.length()
> + (pos > 0 ? pos : this.bufferlen) - this.bufferpos;
> if (currentLen >= maxLineLen) {
> throw new MessageConstraintException("Maximum line length 
> limit exceeded");
> }
> }
> {code}
> If LF chanced to be at the beginning of the buffer, {{currentLen}} is 
> calculated incorrectly. It should be {{this.linebuffer.length() + pos - 
> this.bufferpos}}, so, effectively {{this.linebuffer.length() + 0 - 0}}.
> E.g. if maxLineLen=1, buffer.length=8192 (the default setting), a line is 
> 9000, then it doesn't fit the buffer, thus it's 1st part is read into 
> {{linebuffer}}, 2nd part is read into {{buffer}}. If the 9000 line's 
> terminating LF chances to be the 1st char of that buffer, and after that line 
> it follows more header data, say, exceeding 8192 bytes - then the code 
> calculates {{currentLen = linebuffer.length() + bufferlen - bufferpos = 9000+ 
> 8192 - 0}} > 1, while actual line length is just 9000.
> I think the fix is to replace {{(pos > 0 ? pos : this.bufferlen)}} to {{(pos 
> > -1 ? pos : this.bufferlen)}}



--
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] (HTTPCORE-472) incorrect "Maximum line length limit exceeded" detection is possible

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050360#comment-16050360
 ] 

ASF subversion and git services commented on HTTPCORE-472:
--

Commit 721b50f56f5d3f4914f057ec79883d9a372ef076 in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=721b50f ]

HTTPCORE-472: Fixed problem with blocking message parsers incorrectly throwing 
"Maximum line length limit exceeded" exception in some corner cases


> incorrect "Maximum line length limit exceeded" detection is possible
> 
>
> Key: HTTPCORE-472
> URL: https://issues.apache.org/jira/browse/HTTPCORE-472
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 4.4.6
>Reporter: Artem Nakonechnyy
>Assignee: Oleg Kalnichevski
>
> the error is in 
> org.apache.http.impl.io.SessionInputBufferImpl#readLine(org.apache.http.util.CharArrayBuffer)
> {code}
> if (maxLineLen > 0) {
> final int currentLen = this.linebuffer.length()
> + (pos > 0 ? pos : this.bufferlen) - this.bufferpos;
> if (currentLen >= maxLineLen) {
> throw new MessageConstraintException("Maximum line length 
> limit exceeded");
> }
> }
> {code}
> If LF chanced to be at the beginning of the buffer, {{currentLen}} is 
> calculated incorrectly. It should be {{this.linebuffer.length() + pos - 
> this.bufferpos}}, so, effectively {{this.linebuffer.length() + 0 - 0}}.
> E.g. if maxLineLen=1, buffer.length=8192 (the default setting), a line is 
> 9000, then it doesn't fit the buffer, thus it's 1st part is read into 
> {{linebuffer}}, 2nd part is read into {{buffer}}. If the 9000 line's 
> terminating LF chances to be the 1st char of that buffer, and after that line 
> it follows more header data, say, exceeding 8192 bytes - then the code 
> calculates {{currentLen = linebuffer.length() + bufferlen - bufferpos = 9000+ 
> 8192 - 0}} > 1, while actual line length is just 9000.
> I think the fix is to replace {{(pos > 0 ? pos : this.bufferlen)}} to {{(pos 
> > -1 ? pos : this.bufferlen)}}



--
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] (HTTPCORE-466) Round out the SslContextBuilder by adding missing APIs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16051617#comment-16051617
 ] 

ASF subversion and git services commented on HTTPCORE-466:
--

Commit 46297edb2397a72f47a766f67981583ab52ffebc in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=46297ed ]

[HTTPCORE-466] Round out the SslContextBuilder by adding missing APIs.

Port from branch 4.4.x.


> Round out the SslContextBuilder by adding missing APIs
> --
>
> Key: HTTPCORE-466
> URL: https://issues.apache.org/jira/browse/HTTPCORE-466
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.7, 5.0-alpha4
>
>
> Round out the {{SslContextBuilder}} class by adding missing APIs that are 
> currently hard-coded as:
> - {{TrustManagerFactory.getDefaultAlgorithm()}}
> - {{KeyStore.getDefaultType()}}
> - {{KeyManagerFactory.getDefaultAlgorithm()}}



--
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] (HTTPCORE-490) concurrent bug when invoke future.cancel

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174393#comment-16174393
 ] 

ASF subversion and git services commented on HTTPCORE-490:
--

Commit 41d374cd352d71b725b60ea1c340b01c774eab58 in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=41d374c ]

HTTPCORE-490: session requests do not get cancelled correctly if the associated 
HTTP response fututes get cancelled


> concurrent bug when invoke future.cancel
> 
>
> Key: HTTPCORE-490
> URL: https://issues.apache.org/jira/browse/HTTPCORE-490
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 4.4.7
>Reporter: wenqi.huang
>Assignee: Oleg Kalnichevski
> Fix For: 4.4.8
>
>
> The following code has a bug that the third http invoke will never respond. 
> pay attention to the parameters setted in the code like 
> socketTimeout,maxConnPerRoute,maxConnTotal, etc. and the url invoked must 
> block for 5 seconds at server side(in other worlds, sleep for 5 seconds.)
>  
> {code:java}
> public class AsyncHttpClientTest {
> public static void main(String[] args) throws InterruptedException {
> //please attention to the socketTimeout,maxConnPerRoute,maxConnTotal
> CloseableHttpAsyncClient c = HttpAsyncClientBuilder.create()
> 
> .setDefaultRequestConfig(RequestConfig.custom().setSocketTimeout(4000).build())
> .setMaxConnPerRoute(1).setMaxConnTotal(1).build();
> c.start();
> //this url will block for 5 seconds at server side.
> HttpGet httpGet = new 
> HttpGet("http://localhost:8778/someUrlWillBlockForFiveSecondsAtServerSide;);
> Future f1 = execute(httpGet, c);
> Future f2 = execute(httpGet, c);
> //this http invoke will never success or fail.
> Future f3 = execute(httpGet, c);
> System.out.println("begin");
> Thread.sleep(1000);
> f1.cancel(true);
> f2.cancel(true);
> }
> private static Future execute(HttpGet httpGet, CloseableHttpAsyncClient 
> c){
> return c.execute(httpGet, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
> String ret = null;
> try {
> ret = IOUtils.toString(result.getEntity().getContent());
> } catch (IOException e) {
> e.printStackTrace();
> }
> System.out.println("completed:"+ret);
> }
> @Override
> public void failed(Exception ex) {
> System.out.println("failed");
> ex.printStackTrace();
> }
> @Override
> public void cancelled() {
> System.out.println("cancelled");
> }
> });
> }
> }
> {code}



--
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] (HTTPCORE-494) Add image constants to ContentType

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196035#comment-16196035
 ] 

ASF subversion and git services commented on HTTPCORE-494:
--

Commit a42fd24b8da58dc999d2c051776231c570a51341 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=a42fd24 ]

[HTTPCORE-494] Add image constants to ContentType.


> Add image constants to ContentType
> --
>
> Key: HTTPCORE-494
> URL: https://issues.apache.org/jira/browse/HTTPCORE-494
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9
>
>
> Add image constants to ContentType:
> - org.apache.hc.core5.http.ContentType.IMAGE_BMP
> - org.apache.hc.core5.http.ContentType.IMAGE_GIF
> - org.apache.hc.core5.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core5.http.ContentType.IMAGE_PNG
> - org.apache.hc.core5.http.ContentType.IMAGE_WEBP
> Also:
> - org.apache.hc.core.http.ContentType.IMAGE_BMP
> - org.apache.hc.core.http.ContentType.IMAGE_GIF
> - org.apache.hc.core.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core.http.ContentType.IMAGE_PNG
> - org.apache.hc.core.http.ContentType.IMAGE_WEBP



--
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] (HTTPCORE-494) Add image constants to ContentType

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193356#comment-16193356
 ] 

ASF subversion and git services commented on HTTPCORE-494:
--

Commit 1e0ba1011f5686dbd89a8e2f6caa1d6198f910ae in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=1e0ba10 ]

[HTTPCORE-494] Add image constants to ContentType.

> Add image constants to ContentType
> --
>
> Key: HTTPCORE-494
> URL: https://issues.apache.org/jira/browse/HTTPCORE-494
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Add image constants to ContentType:
> - org.apache.hc.core5.http.ContentType.IMAGE_BMP
> - org.apache.hc.core5.http.ContentType.IMAGE_GIF
> - org.apache.hc.core5.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core5.http.ContentType.IMAGE_PNG
> - org.apache.hc.core5.http.ContentType.IMAGE_WEBP
> Also:
> - org.apache.hc.core.http.ContentType.IMAGE_BMP
> - org.apache.hc.core.http.ContentType.IMAGE_GIF
> - org.apache.hc.core.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core.http.ContentType.IMAGE_PNG
> - org.apache.hc.core.http.ContentType.IMAGE_WEBP



--
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] (HTTPCORE-494) Add image constants to ContentType

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193321#comment-16193321
 ] 

ASF subversion and git services commented on HTTPCORE-494:
--

Commit 050f0fcf8f0703950f3a2cf47a4a9b4ac4e6aa6c in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=050f0fc ]

[HTTPCORE-494] Add image constants to ContentType.

> Add image constants to ContentType
> --
>
> Key: HTTPCORE-494
> URL: https://issues.apache.org/jira/browse/HTTPCORE-494
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Add image constants to ContentType:
> - org.apache.hc.core5.http.ContentType.IMAGE_BMP
> - org.apache.hc.core5.http.ContentType.IMAGE_GIF
> - org.apache.hc.core5.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core5.http.ContentType.IMAGE_PNG
> - org.apache.hc.core5.http.ContentType.IMAGE_WEBP
> Also:
> - org.apache.hc.core.http.ContentType.IMAGE_BMP
> - org.apache.hc.core.http.ContentType.IMAGE_GIF
> - org.apache.hc.core.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core.http.ContentType.IMAGE_PNG
> - org.apache.hc.core.http.ContentType.IMAGE_WEBP



--
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] (HTTPCORE-494) Add image constants to ContentType

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193366#comment-16193366
 ] 

ASF subversion and git services commented on HTTPCORE-494:
--

Commit ac2a1764a0846a9d24e9790ae39815b073eb4d46 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=ac2a176 ]

[HTTPCORE-494] Add image constants to ContentType.


> Add image constants to ContentType
> --
>
> Key: HTTPCORE-494
> URL: https://issues.apache.org/jira/browse/HTTPCORE-494
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Add image constants to ContentType:
> - org.apache.hc.core5.http.ContentType.IMAGE_BMP
> - org.apache.hc.core5.http.ContentType.IMAGE_GIF
> - org.apache.hc.core5.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core5.http.ContentType.IMAGE_PNG
> - org.apache.hc.core5.http.ContentType.IMAGE_WEBP
> Also:
> - org.apache.hc.core.http.ContentType.IMAGE_BMP
> - org.apache.hc.core.http.ContentType.IMAGE_GIF
> - org.apache.hc.core.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core.http.ContentType.IMAGE_PNG
> - org.apache.hc.core.http.ContentType.IMAGE_WEBP



--
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] (HTTPCORE-494) Add image constants to ContentType

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193307#comment-16193307
 ] 

ASF subversion and git services commented on HTTPCORE-494:
--

Commit 1c17e24cb4a9657d643b42d8c19905778cafe16d in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=1c17e24 ]

[HTTPCORE-494] Add image constants to ContentType.

> Add image constants to ContentType
> --
>
> Key: HTTPCORE-494
> URL: https://issues.apache.org/jira/browse/HTTPCORE-494
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Add image constants to ContentType:
> - org.apache.hc.core5.http.ContentType.IMAGE_BMP
> - org.apache.hc.core5.http.ContentType.IMAGE_GIF
> - org.apache.hc.core5.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core5.http.ContentType.IMAGE_PNG
> - org.apache.hc.core5.http.ContentType.IMAGE_WEBP
> Also:
> - org.apache.hc.core.http.ContentType.IMAGE_BMP
> - org.apache.hc.core.http.ContentType.IMAGE_GIF
> - org.apache.hc.core.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core.http.ContentType.IMAGE_PNG
> - org.apache.hc.core.http.ContentType.IMAGE_WEBP



--
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] (HTTPCORE-494) Add image constants to ContentType

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193352#comment-16193352
 ] 

ASF subversion and git services commented on HTTPCORE-494:
--

Commit 48f8bb20a8fe6701d81c9e31a6326d9608ab3a2e in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=48f8bb2 ]

[HTTPCORE-494] Add image constants to ContentType.

> Add image constants to ContentType
> --
>
> Key: HTTPCORE-494
> URL: https://issues.apache.org/jira/browse/HTTPCORE-494
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Add image constants to ContentType:
> - org.apache.hc.core5.http.ContentType.IMAGE_BMP
> - org.apache.hc.core5.http.ContentType.IMAGE_GIF
> - org.apache.hc.core5.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core5.http.ContentType.IMAGE_PNG
> - org.apache.hc.core5.http.ContentType.IMAGE_WEBP
> Also:
> - org.apache.hc.core.http.ContentType.IMAGE_BMP
> - org.apache.hc.core.http.ContentType.IMAGE_GIF
> - org.apache.hc.core.http.ContentType.IMAGE_JPEG
> - org.apache.hc.core.http.ContentType.IMAGE_PNG
> - org.apache.hc.core.http.ContentType.IMAGE_WEBP



--
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-1827) Provide caching for streamed HTTP exchanges in CachingHttpAsyncClient

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1827:
-

Commit 45f16579078b9d2c27a403e26fc14fd8730e44c4 in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=45f1657 
]

HTTPCLIENT-1827: Builder for CachingHttpAsyncClient instances with full support 
for streamed HTTP exchanges


> Provide caching for streamed HTTP exchanges in CachingHttpAsyncClient 
> --
>
> Key: HTTPCLIENT-1827
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1827
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: Brian Chang
> Fix For: 5.0
>
>
> The current implementation of {{CachingHttpAsyncClient}} doesn't support 
> caching of streaming exchanges. It would be very useful to have this 
> functionality implemented.



--
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-1827) Provide caching for streamed HTTP exchanges in CachingHttpAsyncClient

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1827:
-

Commit 849d1a138e440459aaddf8c4ca52b9f76ceff78d in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=849d1a1 
]

HTTPCLIENT-1827: Asynchronous cache exec interceptor with caching support for 
streamed HTTP exchanges; removed incomplete response checks as response 
integrity is enforced in the transport layer; async cache re-validation is 
currently broken in the classic and unsuppoted in the async implementations


> Provide caching for streamed HTTP exchanges in CachingHttpAsyncClient 
> --
>
> Key: HTTPCLIENT-1827
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1827
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: Brian Chang
> Fix For: 5.0
>
>
> The current implementation of {{CachingHttpAsyncClient}} doesn't support 
> caching of streaming exchanges. It would be very useful to have this 
> functionality implemented.



--
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] (HTTPCORE-488) SingleCoreIOReactor.connect methods timeout parameter do not have effect.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155294#comment-16155294
 ] 

ASF subversion and git services commented on HTTPCORE-488:
--

Commit 6e22c52f689597741503ce2a85881b249f4728f4 in httpcomponents-core's branch 
refs/heads/master from [~silver9886]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=6e22c52 ]

HTTPCORE-488: SingleCoreIOReactor#connect timeout parameter has no effect


> SingleCoreIOReactor.connect methods timeout parameter do not have effect.
> -
>
> Key: HTTPCORE-488
> URL: https://issues.apache.org/jira/browse/HTTPCORE-488
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 5.0-alpha4
>Reporter: silver9886
>Priority: Minor
>
> In my opinion , timeout parameter in connect method means connectTimeout.
> In InternalConnectChannel.onIOEvent ,if (readyOps & SelectionKey.OP_CONNECT) 
> != 0 then the socketChannel will connect to the server.However , at this time,
> Perhaps It is connection time out already.
> So i suggest check connecttimeout at InternalConnectChannel.onIOEvent methods 
> When there is SelectionKey.OP_CONNECT event happend



--
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] (HTTPCORE-489) sometimes unit test will failed

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155459#comment-16155459
 ] 

ASF subversion and git services commented on HTTPCORE-489:
--

Commit 5ea246258b2da559b0645f1ca12cb083948f372e in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=5ea2462 ]

HTTPCORE-489: tweak SSL protocol mismatch test case to work around the problem 
with intermittent failures on Windows


> sometimes unit test will failed
> ---
>
> Key: HTTPCORE-489
> URL: https://issues.apache.org/jira/browse/HTTPCORE-489
> Project: HttpComponents HttpCore
>  Issue Type: Test
>  Components: HttpCore NIO
>Affects Versions: 5.0-alpha4
> Environment: windows 7
> jdk:1.8.0_101
>Reporter: silver9886
>Priority: Trivial
> Fix For: 5.0-beta1
>
> Attachments: SocketException(success case).txt, 
> SSLHandshakeException(failed case).txt
>
>
> org.apache.hc.core5.ssl.TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2()
> sometimes will run failed occasionally.
> for example, change the branch from master to the other banch,run mvn clean 
> test command,
> change back to the master run the command,and change to the other branch ,run 
> command 
> twice change back ,run command(just run more times each branch and change to 
> other branch run command several times).
> Doing steps above for some times, occasionally the unit test failed.
> out put is like this:
> Failed tests:
>   TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2
> Expected: an instance of java.net.SocketException
>  but:  handshake_
> failure> is a javax.net.ssl.SSLHandshakeException
> Stacktrace was: javax.net.ssl.SSLHandshakeException: Received fatal alert: 
> hands
> hake_failure
> the difference exception stack between failed and success test case are in 
> attachment.
> I don't know if you can Recurrent this bug in your environment.And I am not
> sure If it is a bug or just something wrong with my environment.
> If make sure it is a bug,maybe we should except thrown IOException.class when 
> environment is windows and jdk.version
> >= 1.8.



--
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] (HTTPCORE-491) BasicAsyncResponseConsumer can easily be tricked into triggering an OOME

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182701#comment-16182701
 ] 

ASF subversion and git services commented on HTTPCORE-491:
--

Commit 47411d22b3150010ac794a166b7c284be22b82cf in httpcomponents-core's branch 
refs/heads/4.4.x from [~mheemskerk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=47411d2 ]

HTTPCORE-491 Make BasicAsyncRequest|ResponseConsumer more paranoid

BasicAsyncRequestConsumer and BasicAsyncResponseConsumer used to
blindly pre-allocate a buffer of Content-Length. If the request / response
is crafted to have a very large Content-Length header, this can result in
OutOfMemoryErrors.

This limits the initial buffer size to 256kb, while still allowing the
buffer to grow if a larger message is read.


> BasicAsyncResponseConsumer can easily be tricked into triggering an OOME
> 
>
> Key: HTTPCORE-491
> URL: https://issues.apache.org/jira/browse/HTTPCORE-491
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.7
>Reporter: Michael Heemskerk
> Fix For: 4.4.8
>
>
> When using {{BasicAsyncResponseConsumer}} to consume a response, the consumer 
> initializes its {{SimpleInputBuffer}} with the value reported on the 
> response's {{Content-Length}} header.
> It's easy to spoof a response with a very large (but smaller than 
> Integer.MAX_VALUE) {{Content-Length}} header and have the client pre-allocate 
> a massive buffer, triggering an OOME.
> Since {{SimpleInputBuffer}} already expands-on-demand, it would be trivial to 
> cap the initial buffer size to some reasonable limit (256k or even 1M) 



--
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] (HTTPCORE-492) Make org.apache.http.nio.protocol.ErrorResponseProducer public

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16184679#comment-16184679
 ] 

ASF subversion and git services commented on HTTPCORE-492:
--

Commit bb32b01dffc8dde5ddb31a616fac18ca66cc97cf in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=bb32b01 ]

* HTTPCORE-492: Make org.apache.http.nio.protocol.ErrorResponseProducer
public.
  Contributed by Gary Gregory 

* HTTPCORE-493: Make
org.apache.http.nio.protocol.HttpAsyncService.responseFactory available
to subclasses.
  Contributed by Gary Gregory 

> Make org.apache.http.nio.protocol.ErrorResponseProducer public
> --
>
> Key: HTTPCORE-492
> URL: https://issues.apache.org/jira/browse/HTTPCORE-492
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.8
>
>
> Make {{org.apache.http.nio.protocol.ErrorResponseProducer}} a {{public}} 
> class.



--
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] (HTTPCORE-493) Make org.apache.http.nio.protocol.HttpAsyncService.responseFactory available to subclasses

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16184680#comment-16184680
 ] 

ASF subversion and git services commented on HTTPCORE-493:
--

Commit bb32b01dffc8dde5ddb31a616fac18ca66cc97cf in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=bb32b01 ]

* HTTPCORE-492: Make org.apache.http.nio.protocol.ErrorResponseProducer
public.
  Contributed by Gary Gregory 

* HTTPCORE-493: Make
org.apache.http.nio.protocol.HttpAsyncService.responseFactory available
to subclasses.
  Contributed by Gary Gregory 

> Make org.apache.http.nio.protocol.HttpAsyncService.responseFactory available 
> to subclasses
> --
>
> Key: HTTPCORE-493
> URL: https://issues.apache.org/jira/browse/HTTPCORE-493
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.8
>
>
> Make {{org.apache.http.nio.protocol.HttpAsyncService#responseFactory}} 
> available to subclasses by adding the {{protected}} method 
> {{org.apache.http.nio.protocol.HttpAsyncService.getResponseFactory()}}



--
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] (HTTPCORE-491) BasicAsyncResponseConsumer can easily be tricked into triggering an OOME

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16184684#comment-16184684
 ] 

ASF subversion and git services commented on HTTPCORE-491:
--

Commit c70174b337b9d5e79e8811acfe4794582ba880f8 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=c70174b ]

* HTTPCORE-491 Make BasicAsyncRequest|ResponseConsumer more paranoid
  Contributed by Michael Heemskerk 


> BasicAsyncResponseConsumer can easily be tricked into triggering an OOME
> 
>
> Key: HTTPCORE-491
> URL: https://issues.apache.org/jira/browse/HTTPCORE-491
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.7
>Reporter: Michael Heemskerk
> Fix For: 4.4.8
>
>
> When using {{BasicAsyncResponseConsumer}} to consume a response, the consumer 
> initializes its {{SimpleInputBuffer}} with the value reported on the 
> response's {{Content-Length}} header.
> It's easy to spoof a response with a very large (but smaller than 
> Integer.MAX_VALUE) {{Content-Length}} header and have the client pre-allocate 
> a massive buffer, triggering an OOME.
> Since {{SimpleInputBuffer}} already expands-on-demand, it would be trivial to 
> cap the initial buffer size to some reasonable limit (256k or even 1M) 



--
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] (HTTPCORE-490) concurrent bug when invoke future.cancel

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16184685#comment-16184685
 ] 

ASF subversion and git services commented on HTTPCORE-490:
--

Commit 4bf39ed9eab5d2324b73a42583b8b21add917084 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=4bf39ed ]

* HTTPCORE-490: session requests do not get cancelled correctly if the
associated HTTP response fututes get cancelled
  Contributed by Oleg Kalnichevski 


> concurrent bug when invoke future.cancel
> 
>
> Key: HTTPCORE-490
> URL: https://issues.apache.org/jira/browse/HTTPCORE-490
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 4.4.7
>Reporter: wenqi.huang
>Assignee: Oleg Kalnichevski
> Fix For: 4.4.8
>
>
> The following code has a bug that the third http invoke will never respond. 
> pay attention to the parameters setted in the code like 
> socketTimeout,maxConnPerRoute,maxConnTotal, etc. and the url invoked must 
> block for 5 seconds at server side(in other worlds, sleep for 5 seconds.)
>  
> {code:java}
> public class AsyncHttpClientTest {
> public static void main(String[] args) throws InterruptedException {
> //please attention to the socketTimeout,maxConnPerRoute,maxConnTotal
> CloseableHttpAsyncClient c = HttpAsyncClientBuilder.create()
> 
> .setDefaultRequestConfig(RequestConfig.custom().setSocketTimeout(4000).build())
> .setMaxConnPerRoute(1).setMaxConnTotal(1).build();
> c.start();
> //this url will block for 5 seconds at server side.
> HttpGet httpGet = new 
> HttpGet("http://localhost:8778/someUrlWillBlockForFiveSecondsAtServerSide;);
> Future f1 = execute(httpGet, c);
> Future f2 = execute(httpGet, c);
> //this http invoke will never success or fail.
> Future f3 = execute(httpGet, c);
> System.out.println("begin");
> Thread.sleep(1000);
> f1.cancel(true);
> f2.cancel(true);
> }
> private static Future execute(HttpGet httpGet, CloseableHttpAsyncClient 
> c){
> return c.execute(httpGet, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
> String ret = null;
> try {
> ret = IOUtils.toString(result.getEntity().getContent());
> } catch (IOException e) {
> e.printStackTrace();
> }
> System.out.println("completed:"+ret);
> }
> @Override
> public void failed(Exception ex) {
> System.out.println("failed");
> ex.printStackTrace();
> }
> @Override
> public void cancelled() {
> System.out.println("cancelled");
> }
> });
> }
> }
> {code}



--
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-293) Provide support for non-ASCII charsets in the multipart disposition-content header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-293:


Commit a424709d89504aadd7b3d59129902666d79d0c15 in httpcomponents-client's 
branch refs/heads/master from [~sermojohn]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=a424709 
]

HTTPCLIENT-293 Implemented the percent encoding of the filename parameter of 
the Content-Disposition header based on RFC7578 sections 2 and 4.2. In the new 
MultipartForm implementation I included a PercentCodec that performs 
encoding/decoding to/from the percent encoding as described in RFC7578 and 
RFC3986.


> Provide support for non-ASCII charsets in the multipart disposition-content 
> header
> --
>
> Key: HTTPCLIENT-293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 1.0 Alpha
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Dofonsou
>Priority: Minor
> Fix For: 4.0 Beta 2
>
>
> Because of the the following line in getAsciiBytes 
>  data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?



--
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-293) Provide support for non-ASCII charsets in the multipart disposition-content header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-293:


Commit 9560aef4765ec7c50d29cd7ca7ee735bf3a6c3b6 in httpcomponents-client's 
branch refs/heads/master from [~sermojohn]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=9560aef 
]

HTTPCLIENT-293 Refactored code in order to support multipart header field 
parameters in the data model and postpone the formatting and encoding of the 
parameters until the moment written into a stream, which is essential in order 
to avoid multiple encodings of the same value.


> Provide support for non-ASCII charsets in the multipart disposition-content 
> header
> --
>
> Key: HTTPCLIENT-293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 1.0 Alpha
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Dofonsou
>Priority: Minor
> Fix For: 4.0 Beta 2
>
>
> Because of the the following line in getAsciiBytes 
>  data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?



--
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-293) Provide support for non-ASCII charsets in the multipart disposition-content header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-293:


Commit 278e47d277568045ab8ff3c42677c791f0227d03 in httpcomponents-client's 
branch refs/heads/4.6.x from [~sermojohn]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=278e47d 
]

HTTPCLIENT-293 Implemented the percent encoding of the filename parameter of 
the Content-Disposition header based on RFC7578 sections 2 and 4.2. In the new 
MultipartForm implementation I included a PercentCodec that performs 
encoding/decoding to/from the percent encoding as described in RFC7578 and 
RFC3986.

Closes #85


> Provide support for non-ASCII charsets in the multipart disposition-content 
> header
> --
>
> Key: HTTPCLIENT-293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 1.0 Alpha
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Dofonsou
>Priority: Minor
> Fix For: 4.0 Beta 2
>
>
> Because of the the following line in getAsciiBytes 
>  data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?



--
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-293) Provide support for non-ASCII charsets in the multipart disposition-content header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-293:


Commit 7aef825326a9accca5b1fb8c0ee82597ac7105d6 in httpcomponents-client's 
branch refs/heads/master from [~sermojohn]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=7aef825 
]

HTTPCLIENT-293 Refactored code in order to support multipart header field 
parameters in the data model and postpone the formatting and encoding of the 
parameters until the moment written into a stream, which is essential in order 
to avoid multiple encodings of the same value.


> Provide support for non-ASCII charsets in the multipart disposition-content 
> header
> --
>
> Key: HTTPCLIENT-293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 1.0 Alpha
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Dofonsou
>Priority: Minor
> Fix For: 4.0 Beta 2
>
>
> Because of the the following line in getAsciiBytes 
>  data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?



--
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-293) Provide support for non-ASCII charsets in the multipart disposition-content header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-293:


Commit 582b28060335c443f971b7fe02bbfc9f3d44bf44 in httpcomponents-client's 
branch refs/heads/4.6.x from [~sermojohn]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=582b280 
]

HTTPCLIENT-293 Refactored code in order to support multipart header field 
parameters in the data model and postpone the formatting and encoding of the 
parameters until the moment written into a stream, which is essential in order 
to avoid multiple encodings of the same value.


> Provide support for non-ASCII charsets in the multipart disposition-content 
> header
> --
>
> Key: HTTPCLIENT-293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 1.0 Alpha
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Dofonsou
>Priority: Minor
> Fix For: 4.0 Beta 2
>
>
> Because of the the following line in getAsciiBytes 
>  data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?



--
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-293) Provide support for non-ASCII charsets in the multipart disposition-content header

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-293:


Commit b017a1f2b9b8e12f913843f58137962502d343a8 in httpcomponents-client's 
branch refs/heads/master from [~sermojohn]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=b017a1f 
]

HTTPCLIENT-293 Implemented the percent encoding of the filename parameter of 
the Content-Disposition header based on RFC7578 sections 2 and 4.2. In the new 
MultipartForm implementation I included a PercentCodec that performs 
encoding/decoding to/from the percent encoding as described in RFC7578 and 
RFC3986.


> Provide support for non-ASCII charsets in the multipart disposition-content 
> header
> --
>
> Key: HTTPCLIENT-293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-293
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 1.0 Alpha
> Environment: Operating System: All
> Platform: All
>Reporter: Eric Dofonsou
>Priority: Minor
> Fix For: 4.0 Beta 2
>
>
> Because of the the following line in getAsciiBytes 
>  data.getBytes("US-ASCII");
> The returned string is modified if has Latin Characters.
> Ex : Document non-controlé -> Document non-control?



--
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-1855) Digest auth: Nonce counter not incremented after reuse

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1855:
-

Commit 7e44b9635e5de8ffce100f4ce4fc3e5d0dedb63b in httpcomponents-client's 
branch refs/heads/4.5.x from alessandro.gherardi
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=7e44b96 
]

HTTPCLIENT-1855: Update DIGEST nonce counter in auth cache after auth challenge


> Digest auth: Nonce counter not incremented after reuse
> --
>
> Key: HTTPCLIENT-1855
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1855
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Alessandro Gherardi
>Assignee: Oleg Kalnichevski
> Fix For: 5.0 Alpha3
>
> Attachments: HttpClientDigest.java, wireshark.txt
>
>
> I have a client app using httpclient 4.5.2 with BasicCredentialsProvider and 
> BasicAuthCache. and web server that requires HTTP digest authentication. 
> The client sends 3 requests to the web server. 
> When the app sends the first request, the server returns an HTTP 401 with a 
> digest challenge. httpclient automatically retries the request with the 
> Authorization header. The header contains the nonce returned by the server 
> and a nonce counter (nc) of 1. The retry succeeds and httpclient caches the 
> DigestScheme.
> For the second request, httpclient uses the cached DigestScheme to calculate 
> the Authorization header pre-emptively. The header contains the same nonce 
> and specifies a nonce counter of 2. The request succeed without requiring a 
> retry.
> For the third request, httpclient uses the cached DigestScheme to calculate 
> the Authorization header pre-emptively. Even though the header contains the 
> same nonce, the nonce counter is set to 2 again. This causes the server to 
> return a 401. httpclient should have incremented the nonce counter to 3.
> I believe that the root cause of this problem is that, although DigestScheme 
> increases the nonceCount field every time the authenticate() method is 
> called, HttpAuthenticator does not re-cache DigestScheme after reusing it. 
> The re-cache is needed because BasicAuthCache stores DigestScheme in 
> serialized format.



--
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-1855) Digest auth: Nonce counter not incremented after reuse

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1855:
-

Commit c82799f1eb29e3f74bac0c7be61c8f3e37d702e4 in httpcomponents-client's 
branch refs/heads/4.6.x from alessandro.gherardi
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=c82799f 
]

HTTPCLIENT-1855: Update DIGEST nonce counter in auth cache after auth challenge


> Digest auth: Nonce counter not incremented after reuse
> --
>
> Key: HTTPCLIENT-1855
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1855
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
>Reporter: Alessandro Gherardi
>Assignee: Oleg Kalnichevski
> Fix For: 5.0 Alpha3
>
> Attachments: HttpClientDigest.java, wireshark.txt
>
>
> I have a client app using httpclient 4.5.2 with BasicCredentialsProvider and 
> BasicAuthCache. and web server that requires HTTP digest authentication. 
> The client sends 3 requests to the web server. 
> When the app sends the first request, the server returns an HTTP 401 with a 
> digest challenge. httpclient automatically retries the request with the 
> Authorization header. The header contains the nonce returned by the server 
> and a nonce counter (nc) of 1. The retry succeeds and httpclient caches the 
> DigestScheme.
> For the second request, httpclient uses the cached DigestScheme to calculate 
> the Authorization header pre-emptively. The header contains the same nonce 
> and specifies a nonce counter of 2. The request succeed without requiring a 
> retry.
> For the third request, httpclient uses the cached DigestScheme to calculate 
> the Authorization header pre-emptively. Even though the header contains the 
> same nonce, the nonce counter is set to 2 again. This causes the server to 
> return a 401. httpclient should have incremented the nonce counter to 3.
> I believe that the root cause of this problem is that, although DigestScheme 
> increases the nonceCount field every time the authenticate() method is 
> called, HttpAuthenticator does not re-cache DigestScheme after reusing it. 
> The re-cache is needed because BasicAuthCache stores DigestScheme in 
> serialized format.



--
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] (HTTPCORE-483) High CPU usage after enabling chunked https responses

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16141423#comment-16141423
 ] 

ASF subversion and git services commented on HTTPCORE-483:
--

Commit 9caf4e6376c447591a6725e9d34f3b94e262d87a in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=9caf4e6 ]

HTTPCORE-483: back-ported SSL session termination bug fix from 5.x


> High CPU usage after enabling chunked https responses
> -
>
> Key: HTTPCORE-483
> URL: https://issues.apache.org/jira/browse/HTTPCORE-483
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.6
> Environment: Centos 7
>Reporter: Nick Cabatoff
> Attachments: fg1-initial-unchunked.svg, fg2-initial-chunked.svg, 
> fg3-patched-unchunked.svg, fg4-patched-chunked.svg
>
>
> I wanted persistent connections with keep-alives, and I discovered that the 
> reason I wasn't getting them was because my responses didn't have a 
> content-length or transfer-encoding: chunked.  So I did body.setChunked( true 
> ), passed that to response.setEntity(), and it worked.  But I noticed that my 
> app was pegged at 100% CPU in top.  I found that the app was fine when it 
> started, but after servicing a single HTTPS request with chunked responses, 
> it got stuck in this 100% cpu state.  It turns out that the reactor thread 
> was busy looping:  despite there being no connections open after servicing 
> that one request, in AbstractIOReactor.execute() the selector.select() call 
> continued to return non-zero, and processEvent() always found a key that was 
> writable.  Stepping through the code I noticed that 
> SSLIOSession.updateEventMask() wasn't closing the session:
> {noformat}
> // Graceful session termination
> if (this.status == CLOSING && this.sslEngine.isOutboundDone()
> && (this.endOfStream || this.sslEngine.isInboundDone())) {
> this.status = CLOSED;
> }
> {noformat}
> The status was CLOSING and endOfStream was true, but 
> sslEngine.isOutboundDone() returned false.  
> I looked at httpcore 5 and found that a new check had been added just above:
> {noformat}
> diff --git 
> a/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java
>  
> b/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java
> --- 
> a/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java
> +++ 
> b/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java
> @@ -371,6 +371,11 @@
>  
>  private void updateEventMask() {
>  // Graceful session termination
> +if (this.status == CLOSING && !this.outEncrypted.hasData()) {
> +this.sslEngine.closeOutbound();
> +}
> +
> +// Graceful session termination
>  if (this.status == CLOSING && this.sslEngine.isOutboundDone()
>  && (this.endOfStream || this.sslEngine.isInboundDone())) {
>  this.status = CLOSED;
> {noformat}
> I applied this patch to my httpcore 4.4.6 and the problem went away.  Now 
> after servicing a request with chunked responses the session gets closed 
> properly and the reactor is properly idle. 
> There's still another problem outstanding though.  Request processing now 
> consumes way more CPU than it used to.  Doing one request per second without 
> chunked responses, my app consumes ~20% of one core; with chunked responses 
> it's closer to 100%.  
> I'm attaching flame graphs (see 
> [http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html]): (1) my 
> starting point without chunked respones; (2) with chunked respones; (3) after 
> applying the above patch, without chunked responses; (4) after applying 
> patch, with chunked responses.  Note the similarity between (2) and (4): in 
> both cases, much of the Java code (green) is mostly consumed with epoll calls.



--
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] (HTTPCORE-485) Delete one unused buffer from SSLIOSession.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16142722#comment-16142722
 ] 

ASF subversion and git services commented on HTTPCORE-485:
--

Commit 271c053d4b6e8b827e29715712d7faf0f975dcbf in httpcomponents-core's branch 
refs/heads/4.4.x from [~TodorBonchev]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=271c053 ]

HTTPCORE-485: Remove one buffer from SSLIOSession.java because it is not used.

Currently for each remote connection we make an SSLIOSession.
Each SSLIOSession has 4 buffers:
private final SSLBuffer inEncrypted;
private final SSLBuffer outEncrypted;
private final SSLBuffer inPlain;
private final SSLBuffer outPlain;
And each of these buffers occupies 16K (64K per remote connection).
If an application uses NIO for long polling and there are (for example) 9000 
idle long polling connections waiting for notifications.
This makes 9000 * 64K = 576 000K (576MB).
As outPlain buffer is not used if we remove it this will save 25% of the memory 
from the buffers used for the remote connections. In the example case this is 
144MB.


> Delete one unused buffer from SSLIOSession.
> ---
>
> Key: HTTPCORE-485
> URL: https://issues.apache.org/jira/browse/HTTPCORE-485
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: Todor Bonchev
> Attachments: SSLIOSession.java.patch
>
>
> Currently for each remote connection we make an SSLIOSession.
> Each SSLIOSession has 4 buffers:
> private final SSLBuffer inEncrypted;
> private final SSLBuffer outEncrypted;
> private final SSLBuffer inPlain;
> private final SSLBuffer outPlain;
> And each of these buffers occupies 16K (64K per remote connection).
> Our application uses NIO for long polling and we have 9000 idle long polling 
> connections waiting for notifications.
> This makes 9000 * 64K = 576 000K (576MB).
> I checked the code and saw that the outPlain buffer is not used.
> I tested the code without it and everything worked fine.
> If we remove this buffer it will save 25% of the memory from the buffers used 
> for the remote connections. In our case this is 144MB.
> Here is a proposed patch for SSLIOSession.java that removes the unused buffer.
> Regards,
> Todor Bonchev



--
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] (HTTPCORE-485) Delete one unused buffer from SSLIOSession.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16142720#comment-16142720
 ] 

ASF subversion and git services commented on HTTPCORE-485:
--

Commit 09ca1b5f49cacc36d9309b1bfa5d3489f68939b8 in httpcomponents-core's branch 
refs/heads/master from [~TodorBonchev]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=09ca1b5 ]

HTTPCORE-485: Remove one buffer from SSLIOSession.java because it is not used.

Currently for each remote connection we make an SSLIOSession.
Each SSLIOSession has 4 buffers:
private final SSLBuffer inEncrypted;
private final SSLBuffer outEncrypted;
private final SSLBuffer inPlain;
private final SSLBuffer outPlain;
And each of these buffers occupies 16K (64K per remote connection).
If an application uses NIO for long polling and there are (for example) 9000 
idle long polling connections waiting for notifications.
This makes 9000 * 64K = 576 000K (576MB).
As outPlain buffer is not used if we remove it this will save 25% of the memory 
from the buffers used for the remote connections. In the example case this is 
144MB.


> Delete one unused buffer from SSLIOSession.
> ---
>
> Key: HTTPCORE-485
> URL: https://issues.apache.org/jira/browse/HTTPCORE-485
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: Todor Bonchev
> Attachments: SSLIOSession.java.patch
>
>
> Currently for each remote connection we make an SSLIOSession.
> Each SSLIOSession has 4 buffers:
> private final SSLBuffer inEncrypted;
> private final SSLBuffer outEncrypted;
> private final SSLBuffer inPlain;
> private final SSLBuffer outPlain;
> And each of these buffers occupies 16K (64K per remote connection).
> Our application uses NIO for long polling and we have 9000 idle long polling 
> connections waiting for notifications.
> This makes 9000 * 64K = 576 000K (576MB).
> I checked the code and saw that the outPlain buffer is not used.
> I tested the code without it and everything worked fine.
> If we remove this buffer it will save 25% of the memory from the buffers used 
> for the remote connections. In our case this is 144MB.
> Here is a proposed patch for SSLIOSession.java that removes the unused buffer.
> Regards,
> Todor Bonchev



--
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] (HTTPCORE-487) org.apache.http.nio.reactor.ssl.SSLIOSession and SSLNHttpClientConnectionFactory do not always use the HTTP host setting

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149045#comment-16149045
 ] 

ASF subversion and git services commented on HTTPCORE-487:
--

Commit f12e09eb3cd3cc5dd45b2fcf4f3f81c03eb9d20b in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=f12e09e ]

[HTTPCORE-487] org.apache.http.nio.reactor.ssl.SSLIOSession and
SSLNHttpClientConnectionFactory do not always use the HTTP host setting.

> org.apache.http.nio.reactor.ssl.SSLIOSession and 
> SSLNHttpClientConnectionFactory do not always use the HTTP host setting
> 
>
> Key: HTTPCORE-487
> URL: https://issues.apache.org/jira/browse/HTTPCORE-487
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.6
>Reporter: Gary Gregory
>Priority: Blocker
> Attachments: httpcomponents-core-4.4.x.patch
>
>
> org.apache.http.nio.reactor.ssl.SSLIOSession does not always account for its 
> host setting.
> Patch forthcoming.
> This shows up in the example {{NHttpReverseProxy}} app.
> From the dev ML where I wrote:
> {noformat}
> HttpCore NIO, NHttpReverseProxy and diagnosing an SSL handshake_failure 
> Inbox
> x 
> Gary Gregory 
> 2:57 PM (7 hours ago)
> to HttpComponents 
> Hi All:
> To diagnose a problem I am seeing in my custom HC-NIO proxy, I run our 
> example NHttpReverseProxy with the command line arguments:
> https://jsonplaceholder.typicode.com:443/ 33000 TrustSelfSignedStrategy
> (with or without TrustSelfSignedStrategy)
> Then I get a handshake_failure trying to access it:
> $ curl http://localhost:33000/posts
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 10039  100390 0 39  0  0:00:01 --:--:--  0:00:01   
> 207Received fatal alert: handshake_failure
> NHttpReverseProxy prints:
> Using TrustSelfSignedStrategy (not for production)
> Reverse proxy to https://jsonplaceholder.typicode.com:443
> [client->proxy] connection open 0:0:0:0:0:0:0:1:33000<->0:0:0:0:0:0:0:1:55252
> [client->proxy] 0001 GET /posts HTTP/1.1
> [client->proxy] 0001 request completed
> [proxy->origin] connection open 192.168.0.92:55254<->104.31.87.157:443
> [proxy->origin] 0001 GET /posts HTTP/1.1
> [proxy->origin] 0001 request completed
> [client<-proxy] 0001 javax.net.ssl.SSLException: Received fatal alert: 
> handshake_failure
> [proxy->origin] connection released 0.0.0.0:55254<->104.31.87.157:443
> [proxy->origin] [total kept alive: 0; total allocated: 0 of 100]
> [proxy->origin] connection closed 0.0.0.0:55254<->104.31.87.157:443
> [client->proxy] connection closed 0.0.0.0:33000<->0:0:0:0:0:0:0:1:55252
> HttpClient works fine with:
> public class HttpsClientSanityTest {
> private void executeHttpsGetPosts(final CloseableHttpClient client) 
> throws IOException, ClientProtocolException {
> try (final CloseableHttpResponse reponse = client.execute(new 
> HttpGet("https://jsonplaceholder.typicode.com/posts;))) {
> final String string = EntityUtils.toString(reponse.getEntity());
> Assert.assertNotNull(string);
> // System.out.println(string);
> }
> }
> @Test
> public void test_typicode_com() throws KeyManagementException, 
> NoSuchAlgorithmException, ClientProtocolException, IOException {
> try (final CloseableHttpClient client = HttpClients.createDefault()) {
> executeHttpsGetPosts(client);
> }
> }
> }
> curl works fine with 'curl https://jsonplaceholder.typicode.com/posts' and 
> returns a JSON document.
> Any hints as to what is missing from NHttpReverseProxy?
> Thank you,
> Gary
> Gary Gregory 
> 3:19 PM (7 hours ago)
> to HttpComponents 
> I should add that I am running the latest Oracle Java 8 on Windows 10.
> Gary Gregory 
> 10:17 PM (21 minutes ago)
> to HttpComponents 
> If I set -Djavax.net.debug=all in the proxy I see:
> RandomCookie:  GMT: 1487308723 bytes = { 46, 102, 239, 247, 53, 87, 164, 146, 
> 197, 44, 72, 95, 153, 58, 9, 22, 138, 176, 137, 76, 196, 163, 34, 95, 220, 
> 87, 105, 237 }
> Session ID:  {}
> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
> 

[jira] [Commented] (HTTPCORE-486) SingleCoreIOReactor.processPendingChannels and processPendingConnectionRequests should setting time limit

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150280#comment-16150280
 ] 

ASF subversion and git services commented on HTTPCORE-486:
--

Commit dc2e9285a33d0ad05b4447d8d20b0868f8cde367 in httpcomponents-core's branch 
refs/heads/master from [~silver9886]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=dc2e928 ]

HTTPCORE-486: setting time limit on processPending methods

setting time limit to avoid the SingleCoreIOReactor's time be exhausted
and then  block the remaining work to do.

Closes PR #50


> SingleCoreIOReactor.processPendingChannels and 
> processPendingConnectionRequests should setting time limit
> -
>
> Key: HTTPCORE-486
> URL: https://issues.apache.org/jira/browse/HTTPCORE-486
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Affects Versions: 5.0-alpha3
>Reporter: silver9886
>
> in processPendingChannels method
>  while ((socketChannel = this.channelQueue.poll()) != null) {
> }
> do not have the time limit.If there are too many socketChannel  in the 
> channelQueue
> or there is channelQueue.add in the loop,the SingleCoreIOReactor time will be 
> exhausted
> .That's will block the remaining work to do.
> I suggest using the following code:
> for (int i = 0 ;i < 10 && (socketChannel = this.channelQueue.poll()) != 
> null;++i) {
> }
> the processPendingConnectionRequests method is the same



--
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-1873) Kerberos delegation no longer working after HTTPCLIENT-1736 patch in version 4.5.3

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1873:
-

Commit cc58de13c5361d5ff98a839adc7b46eceb2f2bef in httpcomponents-client's 
branch refs/heads/4.6.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=cc58de1 
]

HTTPCLIENT-1873: Config option for Kerberos delegation


> Kerberos delegation no longer working after HTTPCLIENT-1736 patch in version 
> 4.5.3
> --
>
> Key: HTTPCLIENT-1873
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1873
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic), HttpClient (Windows)
>Affects Versions: 4.5.3, 4.5.4
> Environment: Windows,Linux
>Reporter: Ulrich Colby
>Priority: Minor
>  Labels: easyfix
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> In version 4.5.3, the following fix got applied to the httpclient library:
> _ [HTTPCLIENT-1736] do not request cred delegation by default when using 
> Kerberos auth.
>   Contributed by Oleg Kalnichevski _
> Although it says "by default", when looking at the affected code it's not the 
> case (i.e.: there is no way to request if we want it).  From our tests and my 
> understanding of Kerberos, if a user account is not allowed to be used for 
> delegation, then you can still request delegation, but when creating the user 
> token, it'll simply not be applied.
> +Affected area+:
> In the class "GSSSchemeBase", in the method "createGSSContext", we need the 
> following line added back:
> *gssContext.requestCredDeleg(true);*
> **OR**
> If you insist of leaving it off for a reason I'm not aware of, having a way, 
> maybe through a system property, to say that we want it.
> _IMHO, one of the main reason for using Kerberos in an enterprise environment 
> is to be able to make use of delegation (double hop scenarios)._



--
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-1873) Kerberos delegation no longer working after HTTPCLIENT-1736 patch in version 4.5.3

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1873:
-

Commit a4030759487b4663ed24f4bf8c27eb010efda75b in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=a403075 
]

HTTPCLIENT-1873: Config option for Kerberos delegation


> Kerberos delegation no longer working after HTTPCLIENT-1736 patch in version 
> 4.5.3
> --
>
> Key: HTTPCLIENT-1873
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1873
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic), HttpClient (Windows)
>Affects Versions: 4.5.3, 4.5.4
> Environment: Windows,Linux
>Reporter: Ulrich Colby
>Priority: Minor
>  Labels: easyfix
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> In version 4.5.3, the following fix got applied to the httpclient library:
> _ [HTTPCLIENT-1736] do not request cred delegation by default when using 
> Kerberos auth.
>   Contributed by Oleg Kalnichevski _
> Although it says "by default", when looking at the affected code it's not the 
> case (i.e.: there is no way to request if we want it).  From our tests and my 
> understanding of Kerberos, if a user account is not allowed to be used for 
> delegation, then you can still request delegation, but when creating the user 
> token, it'll simply not be applied.
> +Affected area+:
> In the class "GSSSchemeBase", in the method "createGSSContext", we need the 
> following line added back:
> *gssContext.requestCredDeleg(true);*
> **OR**
> If you insist of leaving it off for a reason I'm not aware of, having a way, 
> maybe through a system property, to say that we want it.
> _IMHO, one of the main reason for using Kerberos in an enterprise environment 
> is to be able to make use of delegation (double hop scenarios)._



--
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-1883) Add https.proxy* documentation to HttpClientBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1883:
-

Commit 8c4e081ecd02e575dff2ab4172962c96846ae8f7 in httpcomponents-client's 
branch refs/heads/4.5.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=8c4e081 
]

HTTPCLIENT-1883: SystemDefaultCredentialsProvider to use https.proxy* system 
properties for origins with port 443


> Add https.proxy* documentation to HttpClientBuilder
> ---
>
> Key: HTTPCLIENT-1883
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1883
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>  Labels: documentation
>
> To amend HTTPCLIENT-1128 I guess...
> I find the list of [{{http.proxy*}} system properties in the type Javadoc for 
> {{HttpClientBuilder}}|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/HttpClientBuilder.java#L140]
>  a bit misleading.
> The JVM distinguishes between HTTP and HTTPS proxy settings (decide for 
> yourself how much sense that makes) but the Javadoc comment only talks about 
> {{http.proxy*}} system properties and not {{https.proxy*}} system properties. 
> One might come to the conclusion that by using {{#useSystemProperties()}} on 
> the builder you'd only get proxy support for HTTP connections but not for 
> HTTPS. 
> Adding a short note about that would be appropriate IMO.



--
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-1883) Add https.proxy* documentation to HttpClientBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1883:
-

Commit 7b7cdd1fd8a6a95e4461ccd3ba12f9501d51c496 in httpcomponents-client's 
branch refs/heads/4.6.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=7b7cdd1 
]

HTTPCLIENT-1883: SystemDefaultCredentialsProvider to use https.proxy* system 
properties for origins with port 443


> Add https.proxy* documentation to HttpClientBuilder
> ---
>
> Key: HTTPCLIENT-1883
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1883
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>  Labels: documentation
>
> To amend HTTPCLIENT-1128 I guess...
> I find the list of [{{http.proxy*}} system properties in the type Javadoc for 
> {{HttpClientBuilder}}|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/HttpClientBuilder.java#L140]
>  a bit misleading.
> The JVM distinguishes between HTTP and HTTPS proxy settings (decide for 
> yourself how much sense that makes) but the Javadoc comment only talks about 
> {{http.proxy*}} system properties and not {{https.proxy*}} system properties. 
> One might come to the conclusion that by using {{#useSystemProperties()}} on 
> the builder you'd only get proxy support for HTTP connections but not for 
> HTTPS. 
> Adding a short note about that would be appropriate IMO.



--
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-1883) Add https.proxy* documentation to HttpClientBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1883:
-

Commit 2584dbd311d5399f121b891ce386c2c168b69a2e in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=2584dbd 
]

HTTPCLIENT-1883: Added https.proxy* to the list of system properties taken into 
account by HttpClientBuilder and HttpAsyncClientBuilder


> Add https.proxy* documentation to HttpClientBuilder
> ---
>
> Key: HTTPCLIENT-1883
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1883
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>  Labels: documentation
>
> To amend HTTPCLIENT-1128 I guess...
> I find the list of [{{http.proxy*}} system properties in the type Javadoc for 
> {{HttpClientBuilder}}|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/HttpClientBuilder.java#L140]
>  a bit misleading.
> The JVM distinguishes between HTTP and HTTPS proxy settings (decide for 
> yourself how much sense that makes) but the Javadoc comment only talks about 
> {{http.proxy*}} system properties and not {{https.proxy*}} system properties. 
> One might come to the conclusion that by using {{#useSystemProperties()}} on 
> the builder you'd only get proxy support for HTTP connections but not for 
> HTTPS. 
> Adding a short note about that would be appropriate IMO.



--
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-1883) Add https.proxy* documentation to HttpClientBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1883:
-

Commit 2b2dd593a356a57bb6d49be582f635c459c0ffce in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=2b2dd59 
]

HTTPCLIENT-1883: SystemDefaultCredentialsProvider to use https.proxy* system 
properties for origins with port 443


> Add https.proxy* documentation to HttpClientBuilder
> ---
>
> Key: HTTPCLIENT-1883
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1883
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>  Labels: documentation
>
> To amend HTTPCLIENT-1128 I guess...
> I find the list of [{{http.proxy*}} system properties in the type Javadoc for 
> {{HttpClientBuilder}}|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/HttpClientBuilder.java#L140]
>  a bit misleading.
> The JVM distinguishes between HTTP and HTTPS proxy settings (decide for 
> yourself how much sense that makes) but the Javadoc comment only talks about 
> {{http.proxy*}} system properties and not {{https.proxy*}} system properties. 
> One might come to the conclusion that by using {{#useSystemProperties()}} on 
> the builder you'd only get proxy support for HTTP connections but not for 
> HTTPS. 
> Adding a short note about that would be appropriate IMO.



--
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-1883) Add https.proxy* documentation to HttpClientBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1883:
-

Commit e9c2a0f6b3141b1808ccad5c39e37ce314db3b95 in httpcomponents-client's 
branch refs/heads/4.6.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=e9c2a0f 
]

HTTPCLIENT-1883: Added https.proxy* to the list of system properties taken into 
account by HttpClientBuilder


> Add https.proxy* documentation to HttpClientBuilder
> ---
>
> Key: HTTPCLIENT-1883
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1883
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>  Labels: documentation
>
> To amend HTTPCLIENT-1128 I guess...
> I find the list of [{{http.proxy*}} system properties in the type Javadoc for 
> {{HttpClientBuilder}}|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/HttpClientBuilder.java#L140]
>  a bit misleading.
> The JVM distinguishes between HTTP and HTTPS proxy settings (decide for 
> yourself how much sense that makes) but the Javadoc comment only talks about 
> {{http.proxy*}} system properties and not {{https.proxy*}} system properties. 
> One might come to the conclusion that by using {{#useSystemProperties()}} on 
> the builder you'd only get proxy support for HTTP connections but not for 
> HTTPS. 
> Adding a short note about that would be appropriate IMO.



--
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-1883) Add https.proxy* documentation to HttpClientBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1883:
-

Commit e249943247833df990c339e17b12209c1d2f4cdb in httpcomponents-client's 
branch refs/heads/4.5.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=e249943 
]

HTTPCLIENT-1883: Added https.proxy* to the list of system properties taken into 
account by HttpClientBuilder


> Add https.proxy* documentation to HttpClientBuilder
> ---
>
> Key: HTTPCLIENT-1883
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1883
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>  Labels: documentation
>
> To amend HTTPCLIENT-1128 I guess...
> I find the list of [{{http.proxy*}} system properties in the type Javadoc for 
> {{HttpClientBuilder}}|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/HttpClientBuilder.java#L140]
>  a bit misleading.
> The JVM distinguishes between HTTP and HTTPS proxy settings (decide for 
> yourself how much sense that makes) but the Javadoc comment only talks about 
> {{http.proxy*}} system properties and not {{https.proxy*}} system properties. 
> One might come to the conclusion that by using {{#useSystemProperties()}} on 
> the builder you'd only get proxy support for HTTP connections but not for 
> HTTPS. 
> Adding a short note about that would be appropriate IMO.



--
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-1886) Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1886:
-

Commit 3689823d1cd42f0b2d87f73d614483ae37504a70 in httpcomponents-client's 
branch refs/heads/4.5.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=3689823 
]

[HTTPCLIENT-1886] Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8.

> Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8
> 
>
> Key: HTTPCLIENT-1886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1886
> Project: HttpComponents HttpClient
>  Issue Type: Task
>Affects Versions: 4.5.4
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8.



--
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-1886) Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1886:
-

Commit ea73f439e90dfda943b5d5e7df3cb26ecdfc158a in httpcomponents-client's 
branch refs/heads/4.5.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=ea73f43 
]

[HTTPCLIENT-1886] Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8.

> Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8
> 
>
> Key: HTTPCLIENT-1886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1886
> Project: HttpComponents HttpClient
>  Issue Type: Task
>Affects Versions: 4.5.4
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Update HttpClient 4.5.x from HttpCore 4.4.7 to 4.4.8.



--
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-1885) 400 Bad Request Server: Microsoft-HTTPAPI/2.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1885:
-

Commit 4a55a8cfbdd7659c76e1354de66eb15a5b066b3b in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=4a55a8c 
]

HTTPCLIENT-1885: Content compression exec interceptor generates incorrect 
'Accept-Encoding' header value


> 400 Bad Request Server: Microsoft-HTTPAPI/2.0
> -
>
> Key: HTTPCLIENT-1885
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1885
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.0 Alpha3
>Reporter: Bernhard Altendorfer
>Priority: Minor
>  Labels: regression
> Fix For: 5.0 Beta1
>
>
> Sending a HTTP GET to http://www.bungalow.net from Postman, cURL and 
> HttpClient 4.5 works and returns a 200.
> Sending the same request from HttpClient 5.0 results in a 400.
> I enabled logging and saw this difference in the response headers:
> Server: Microsoft-IIS/8.0
> Server: Microsoft-HTTPAPI/2.0
> It seems that there is some additional services listening to port 80 on new 
> windows machines and somehow the request from HttpClient 5.0 is forwarded to 
> this one and not the IIS.



--
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-1888) NullPointerException in SystemDefaultCredentialsProvider.getCredentials when AuthScope.orgin is null

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1888:
-

Commit 87e26b7b267b0724d6e4df5627f0e95893a5eae0 in httpcomponents-client's 
branch refs/heads/4.6.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=87e26b7 
]

HTTPCLIENT-1888: Regression in SystemDefaultCredentialsProvider#getCredentials 
causing NPE


> NullPointerException in SystemDefaultCredentialsProvider.getCredentials when 
> AuthScope.orgin is null
> 
>
> Key: HTTPCLIENT-1888
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1888
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.4
>Reporter: Collin Peters
>Priority: Critical
>
> 4.5.4 has the following line in 
> [SystemDefaultCredentialsProvider|https://github.com/apache/httpcomponents-client/blob/4.5.4/httpclient/src/main/java/org/apache/http/impl/client/SystemDefaultCredentialsProvider.java#L114]
>  {code}
>  final String protocol = origin != null ? origin.getSchemeName() : 
> (origin.getPort() == 443 ? "https" : "http");
> {code}
> So 'origin' is still accessed when it is determined that it is null.



--
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-1888) NullPointerException in SystemDefaultCredentialsProvider.getCredentials when AuthScope.orgin is null

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1888:
-

Commit 5bed670873a2e197bc047737d2f0f4518ab94524 in httpcomponents-client's 
branch refs/heads/4.5.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=5bed670 
]

HTTPCLIENT-1888: Regression in SystemDefaultCredentialsProvider#getCredentials 
causing NPE


> NullPointerException in SystemDefaultCredentialsProvider.getCredentials when 
> AuthScope.orgin is null
> 
>
> Key: HTTPCLIENT-1888
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1888
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.4
>Reporter: Collin Peters
>Priority: Critical
>
> 4.5.4 has the following line in 
> [SystemDefaultCredentialsProvider|https://github.com/apache/httpcomponents-client/blob/4.5.4/httpclient/src/main/java/org/apache/http/impl/client/SystemDefaultCredentialsProvider.java#L114]
>  {code}
>  final String protocol = origin != null ? origin.getSchemeName() : 
> (origin.getPort() == 443 ? "https" : "http");
> {code}
> So 'origin' is still accessed when it is determined that it is null.



--
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] (HTTPCORE-499) Make interface Header extend NameValuePair

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288975#comment-16288975
 ] 

ASF subversion and git services commented on HTTPCORE-499:
--

Commit 6abc8da24f906fb3c72a8175008ee3414d9a03c3 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=6abc8da ]

HTTPCORE-499 Make interface Header extend NameValuePair.


> Make interface Header extend NameValuePair 
> ---
>
> Key: HTTPCORE-499
> URL: https://issues.apache.org/jira/browse/HTTPCORE-499
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.8, 5.0-beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Make the interface {{org.apache.hc.core5.http.Header}} extend 
> {{org.apache.hc.core5.http.NameValuePair}}.



--
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] (HTTPCORE-499) Make interface Header extend NameValuePair

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291039#comment-16291039
 ] 

ASF subversion and git services commented on HTTPCORE-499:
--

Commit f316e527e0e3dfde1e79666bad14a17f0d4d8575 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=f316e52 ]

[HTTPCORE-499] Make interface Header extend NameValuePair. BasicHeader
does not extend BasicNameValuePair. Don't create a new empty array all
the time since it is immutable.


> Make interface Header extend NameValuePair 
> ---
>
> Key: HTTPCORE-499
> URL: https://issues.apache.org/jira/browse/HTTPCORE-499
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.8, 5.0-beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9, 5.0-beta2
>
>
> Make the interface {{org.apache.hc.core5.http.Header}} extend 
> {{org.apache.hc.core5.http.NameValuePair}}.



--
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] (HTTPCORE-499) Make interface Header extend NameValuePair

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291126#comment-16291126
 ] 

ASF subversion and git services commented on HTTPCORE-499:
--

Commit 72063bbcacaa4b5b2410e3f614d515c251a333f5 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=72063bb ]

[HTTPCORE-499] Make interface Header extend NameValuePair. BasicHeader
does not extend BasicNameValuePair. This commit brings back hashCode()
and equals() from HTTPCORE-439
(a193709b785373576ab72de4469630b59d985eb5) which might not be all that
good in retrospect of the discussion in HTTPCORE-499.


> Make interface Header extend NameValuePair 
> ---
>
> Key: HTTPCORE-499
> URL: https://issues.apache.org/jira/browse/HTTPCORE-499
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.8, 5.0-beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9, 5.0-beta2
>
>
> Make the interface {{org.apache.hc.core5.http.Header}} extend 
> {{org.apache.hc.core5.http.NameValuePair}}.



--
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] (HTTPCORE-439) Contribute BasicHeader override of equals() and hashCode()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291125#comment-16291125
 ] 

ASF subversion and git services commented on HTTPCORE-439:
--

Commit 72063bbcacaa4b5b2410e3f614d515c251a333f5 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=72063bb ]

[HTTPCORE-499] Make interface Header extend NameValuePair. BasicHeader
does not extend BasicNameValuePair. This commit brings back hashCode()
and equals() from HTTPCORE-439
(a193709b785373576ab72de4469630b59d985eb5) which might not be all that
good in retrospect of the discussion in HTTPCORE-499.


> Contribute BasicHeader override of equals() and hashCode()
> --
>
> Key: HTTPCORE-439
> URL: https://issues.apache.org/jira/browse/HTTPCORE-439
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: Contrib, HttpCore
>Affects Versions: 5.0-alpha2
> Environment: All
>Reporter: John Lewis
> Fix For: 5.0-alpha2
>
>
> When removing headers from a HeaderGroup, the header is only removed if the 
> header you are trying to remove is an object in the header list.  It seems it 
> would be better if headers were removed that matched the name and value of 
> one of the objects in the list.  To accomplish this, I have overridden the 
> equals and hashCode methods in BasicHeader.



--
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] (HTTPCORE-499) Make interface Header extend NameValuePair

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291124#comment-16291124
 ] 

ASF subversion and git services commented on HTTPCORE-499:
--

Commit 72063bbcacaa4b5b2410e3f614d515c251a333f5 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=72063bb ]

[HTTPCORE-499] Make interface Header extend NameValuePair. BasicHeader
does not extend BasicNameValuePair. This commit brings back hashCode()
and equals() from HTTPCORE-439
(a193709b785373576ab72de4469630b59d985eb5) which might not be all that
good in retrospect of the discussion in HTTPCORE-499.


> Make interface Header extend NameValuePair 
> ---
>
> Key: HTTPCORE-499
> URL: https://issues.apache.org/jira/browse/HTTPCORE-499
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.8, 5.0-beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9, 5.0-beta2
>
>
> Make the interface {{org.apache.hc.core5.http.Header}} extend 
> {{org.apache.hc.core5.http.NameValuePair}}.



--
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] (HTTPCORE-439) Contribute BasicHeader override of equals() and hashCode()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295083#comment-16295083
 ] 

ASF subversion and git services commented on HTTPCORE-439:
--

Commit a564f2a9c5205547ed184871108aa35be0ace752 in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=a564f2a ]

Removed #equals and #hashCode methods from BasicHeader added by HTTPCORE-439; 
HeaderGroup#removeHeader to remove the first header matching the header name / 
value passed as a parameter.


> Contribute BasicHeader override of equals() and hashCode()
> --
>
> Key: HTTPCORE-439
> URL: https://issues.apache.org/jira/browse/HTTPCORE-439
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: Contrib, HttpCore
>Affects Versions: 5.0-alpha2
> Environment: All
>Reporter: John Lewis
> Fix For: 5.0-alpha2
>
>
> When removing headers from a HeaderGroup, the header is only removed if the 
> header you are trying to remove is an object in the header list.  It seems it 
> would be better if headers were removed that matched the name and value of 
> one of the objects in the list.  To accomplish this, I have overridden the 
> equals and hashCode methods in BasicHeader.



--
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] (HTTPCORE-501) org.apache.hc.core5.net.URLEncodedUtils.parse() should return a new ArrayList when there are no query parameters

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293258#comment-16293258
 ] 

ASF subversion and git services commented on HTTPCORE-501:
--

Commit 496f5bf390c10626486665ee1c8f859d3dc4888d in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=496f5bf ]

HTTPCORE-501 org.apache.http.client.utils.URLEncodedUtils.parse() should
return a new ArrayList when there are no query parameters.

> org.apache.hc.core5.net.URLEncodedUtils.parse() should return a new ArrayList 
> when there are no query parameters
> 
>
> Key: HTTPCORE-501
> URL: https://issues.apache.org/jira/browse/HTTPCORE-501
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.0-beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> {{org.apache.http.client.utils.URLEncodedUtils.parse(URI, Charset)}} should 
> return a new {{ArrayList}} when there are no query parameters.
> Currently, {{org.apache.http.client.utils.URLEncodedUtils.parse(URI, 
> Charset)}} returns an immutable list through {{Collections.emptyList()}} if 
> there are no params> But if there are parameters, the method returns a 
> mutable list.
> This makes it impossible to write the same code to handle both cases.
> This change will cause the method to return a new {{ArrayList}} if there are 
> no parameters.
> The methods that are directly affected are:
> - org.apache.hc.core5.net.URLEncodedUtils.parse(String, Charset, char...)
> - org.apache.hc.core5.net.URLEncodedUtils.parse(String, Charset)
> - org.apache.hc.core5.net.URLEncodedUtils.parse(URI, Charset)



--
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] (HTTPCORE-499) Make interface Header extend NameValuePair

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288490#comment-16288490
 ] 

ASF subversion and git services commented on HTTPCORE-499:
--

Commit c01ea7ec4a93f45e337b3e24f82ec881106ae0e6 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=c01ea7e ]

HTTPCORE-499 Make interface Header extend NameValuePair.


> Make interface Header extend NameValuePair 
> ---
>
> Key: HTTPCORE-499
> URL: https://issues.apache.org/jira/browse/HTTPCORE-499
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.8, 5.0-beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Make the interface {{org.apache.hc.core5.http.Header}} extend 
> {{org.apache.hc.core5.http.NameValuePair}}.



--
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] (HTTPCORE-499) Make interface Header extend NameValuePair

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288573#comment-16288573
 ] 

ASF subversion and git services commented on HTTPCORE-499:
--

Commit 56c65d47913ed8db37562f26c9e0e6f861a0f61c in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=56c65d4 ]

HTTPCORE-499 Make interface Header extend NameValuePair.


> Make interface Header extend NameValuePair 
> ---
>
> Key: HTTPCORE-499
> URL: https://issues.apache.org/jira/browse/HTTPCORE-499
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.8, 5.0-beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Make the interface {{org.apache.hc.core5.http.Header}} extend 
> {{org.apache.hc.core5.http.NameValuePair}}.



--
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-1824) Async caching module is not async for cache I/O and does not share enough implementation with synchronous client cache

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1824:
-

Commit 002f40f9d3ec65891b5faf086df404dd3c450600 in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=002f40f 
]

HTTPCLIENT-1824, HTTPCLIENT-1868: Asynchronous HTTP cache storage API; 
Memcached backend implementation of async HTTP cache storage


> Async caching module is not async for cache I/O and does not share enough 
> implementation with synchronous client cache
> --
>
> Key: HTTPCLIENT-1824
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1824
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: Jon Moore
>  Labels: cache
> Fix For: 5.0
>
>
> As noted in HTTPASYNC-44, the caching module for the asynchronous client may 
> do synchronous I/O when talking to cache storage; this isn't entirely clean 
> and may violate client assumptions. In addition, there may need to be some 
> refactoring of the synchronous client caching module so that more of the 
> logic can be shared with the asynchronous stack.



--
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-1868) Make memcached storage backend operation non-blocking

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1868:
-

Commit 002f40f9d3ec65891b5faf086df404dd3c450600 in httpcomponents-client's 
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=002f40f 
]

HTTPCLIENT-1824, HTTPCLIENT-1868: Asynchronous HTTP cache storage API; 
Memcached backend implementation of async HTTP cache storage


> Make memcached storage backend operation non-blocking
> -
>
> Key: HTTPCLIENT-1868
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1868
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async)
>Affects Versions: 5.0 Alpha2
>Reporter: Jim Horng
>  Labels: volunteers-wanted
>
> < Context >
> Since `HttpAysncClient` is non-blocking, but it's operation to memcached at 
> `MemcachedHttpCacheStorage` layer still using blocking I/O manner. Even 
> `spymemcached` client which has non-blocking I/O in nature, but 
> `MemcachedHttpCacheStorage` is using `spymemcached` blocking API.
> < Benefit >
> If all the way in flow of `HttpAsyncClient` is non-blocking, then it can 
> truely do high concurrency with just a few threads, otherwise, performance 
> will be largely impact by blocking calls since there's only a few threads for 
> serving http requests.
> < Code Flow for Blocking manner >
> # 
> `org.apache.http.impl.client.cache.memcached.MemcachedHttpCacheStorage#getEntry`
>  -> `final MemcachedCacheEntry mce = reconstituteEntry(client.get(key));` 
> # net.spy.memcached.MemcachedClient#get(java.lang.String)
> Should use `net.spy.memcached.MemcachedClient#asyncGet(java.lang.String)`, 
> but then whole API calling structure require big changes.



--
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-1881) NTLM authentication against ntlm.herokuapp.com

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1881:
-

Commit 42359353a23005b2c12aaa2f98db6c3a47cc53a8 in httpcomponents-client's 
branch refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=4235935 
]

HTTPCLIENT-1881: Allow truncated NTLM packets to work with this client.


> NTLM authentication against ntlm.herokuapp.com
> --
>
> Key: HTTPCLIENT-1881
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1881
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>Assignee: Karl Wright
>  Labels: authentication, ntlm
> Attachments: HTTPCLIENT-1881.patch, msr-ntlm-prototype.zip
>
>
> I'm prototyping NTLM authentication with your 4.5 HTTP client and Spring 
> RestTemplate. This currently fails with a 
> {{org.apache.http.impl.auth.NTLMEngineException}} "NTLM authentication error: 
> NTLM authentication - buffer too small for data item". 
> The code, wire log (below) and a simple standalone test application 
> (attached) are included.
> h2. Code
> {code:java}
> RestTemplate restTemplate = new RestTemplate();
> restTemplate.setRequestFactory(buildHttpComponentsClientHttpRequestFactory(args));
> private static HttpComponentsClientHttpRequestFactory
> buildHttpComponentsClientHttpRequestFactory(String[] args) {
>   PoolingHttpClientConnectionManager cm = new
> PoolingHttpClientConnectionManager();
>   cm.setMaxTotal(128);
>   cm.setDefaultMaxPerRoute(24);
>   RequestConfig.Builder requestBuilder =
> RequestConfig.custom().setConnectTimeout(5000).setSocketTimeout(1);
>   Registry authSchemeRegistry =
> RegistryBuilder.create()
> .register(AuthSchemes.NTLM, new NTLMSchemeFactory())
> .register(AuthSchemes.SPNEGO, new SPNegoSchemeFactory()).build();
>   CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
>   credentialsProvider.setCredentials(AuthScope.ANY, new
> NTCredentials(args[1], args[2], null, args[3]));
>   HttpClientBuilder builder = HttpClientBuilder.create()
> .setConnectionManager(cm)
> .setDefaultRequestConfig(requestBuilder.build())
> .setDefaultAuthSchemeRegistry(authSchemeRegistry)
> .setDefaultCredentialsProvider(credentialsProvider);
>   return new HttpComponentsClientHttpRequestFactory(builder.build());
> }
> {code}
> h2. Wire log
> {noformat}
> 23:21:22,983 | RestTemplate| Created GET request for 
> "https://ntlm.herokuapp.com;
> 23:21:22,987 | RestTemplate| Setting request Accept 
> header to [text/plain, */*]
> 23:21:22,997 | RequestAddCookies   | CookieSpec selected: 
> default
> 23:21:23,006 | RequestAuthCache| Auth cache not set in 
> the context
> 23:21:23,007 | PoolingHttpClientConnectionManager  | Connection request: 
> [route: {s}->https://ntlm.herokuapp.com:443][total kept alive: 0; route 
> allocated: 0 of 24; total allocated: 0 of 128]
> 23:21:23,029 | PoolingHttpClientConnectionManager  | Connection leased: [id: 
> 0][route: {s}->https://ntlm.herokuapp.com:443][total kept alive: 0; route 
> allocated: 1 of 24; total allocated: 1 of 128]
> 23:21:23,031 | MainClientExec  | Opening connection 
> {s}->https://ntlm.herokuapp.com:443
> 23:21:23,299 | DefaultHttpClientConnectionOperator | Connecting to 
> ntlm.herokuapp.com/54.235.146.123:443
> 23:21:23,299 | SSLConnectionSocketFactory  | Connecting socket to 
> ntlm.herokuapp.com/54.235.146.123:443 with timeout 5000
> 23:21:23,581 | SSLConnectionSocketFactory  | Enabled protocols: 
> [TLSv1, TLSv1.1, TLSv1.2]
> 23:21:23,582 | SSLConnectionSocketFactory  | Enabled cipher 
> suites:[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, 

[jira] [Commented] (HTTPCLIENT-1881) NTLM authentication against ntlm.herokuapp.com

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1881:
-

Commit 97eee9e0e0adcb917db20550225db717238f6982 in httpcomponents-client's 
branch refs/heads/4.5.x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=97eee9e 
]

HTTPCLIENT-1881: Allow truncated NTLM packets to work with this client.


> NTLM authentication against ntlm.herokuapp.com
> --
>
> Key: HTTPCLIENT-1881
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1881
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>Assignee: Karl Wright
>  Labels: authentication, ntlm
> Attachments: HTTPCLIENT-1881.patch, msr-ntlm-prototype.zip
>
>
> I'm prototyping NTLM authentication with your 4.5 HTTP client and Spring 
> RestTemplate. This currently fails with a 
> {{org.apache.http.impl.auth.NTLMEngineException}} "NTLM authentication error: 
> NTLM authentication - buffer too small for data item". 
> The code, wire log (below) and a simple standalone test application 
> (attached) are included.
> h2. Code
> {code:java}
> RestTemplate restTemplate = new RestTemplate();
> restTemplate.setRequestFactory(buildHttpComponentsClientHttpRequestFactory(args));
> private static HttpComponentsClientHttpRequestFactory
> buildHttpComponentsClientHttpRequestFactory(String[] args) {
>   PoolingHttpClientConnectionManager cm = new
> PoolingHttpClientConnectionManager();
>   cm.setMaxTotal(128);
>   cm.setDefaultMaxPerRoute(24);
>   RequestConfig.Builder requestBuilder =
> RequestConfig.custom().setConnectTimeout(5000).setSocketTimeout(1);
>   Registry authSchemeRegistry =
> RegistryBuilder.create()
> .register(AuthSchemes.NTLM, new NTLMSchemeFactory())
> .register(AuthSchemes.SPNEGO, new SPNegoSchemeFactory()).build();
>   CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
>   credentialsProvider.setCredentials(AuthScope.ANY, new
> NTCredentials(args[1], args[2], null, args[3]));
>   HttpClientBuilder builder = HttpClientBuilder.create()
> .setConnectionManager(cm)
> .setDefaultRequestConfig(requestBuilder.build())
> .setDefaultAuthSchemeRegistry(authSchemeRegistry)
> .setDefaultCredentialsProvider(credentialsProvider);
>   return new HttpComponentsClientHttpRequestFactory(builder.build());
> }
> {code}
> h2. Wire log
> {noformat}
> 23:21:22,983 | RestTemplate| Created GET request for 
> "https://ntlm.herokuapp.com;
> 23:21:22,987 | RestTemplate| Setting request Accept 
> header to [text/plain, */*]
> 23:21:22,997 | RequestAddCookies   | CookieSpec selected: 
> default
> 23:21:23,006 | RequestAuthCache| Auth cache not set in 
> the context
> 23:21:23,007 | PoolingHttpClientConnectionManager  | Connection request: 
> [route: {s}->https://ntlm.herokuapp.com:443][total kept alive: 0; route 
> allocated: 0 of 24; total allocated: 0 of 128]
> 23:21:23,029 | PoolingHttpClientConnectionManager  | Connection leased: [id: 
> 0][route: {s}->https://ntlm.herokuapp.com:443][total kept alive: 0; route 
> allocated: 1 of 24; total allocated: 1 of 128]
> 23:21:23,031 | MainClientExec  | Opening connection 
> {s}->https://ntlm.herokuapp.com:443
> 23:21:23,299 | DefaultHttpClientConnectionOperator | Connecting to 
> ntlm.herokuapp.com/54.235.146.123:443
> 23:21:23,299 | SSLConnectionSocketFactory  | Connecting socket to 
> ntlm.herokuapp.com/54.235.146.123:443 with timeout 5000
> 23:21:23,581 | SSLConnectionSocketFactory  | Enabled protocols: 
> [TLSv1, TLSv1.1, TLSv1.2]
> 23:21:23,582 | SSLConnectionSocketFactory  | Enabled cipher 
> suites:[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, 

[jira] [Commented] (HTTPCLIENT-1881) NTLM authentication against ntlm.herokuapp.com

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1881:
-

Commit f8a26dffded21be28e1c1ae73f12bb0f42ad29f2 in httpcomponents-client's 
branch refs/heads/4.6.x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=f8a26df 
]

HTTPCLIENT-1881: Allow truncated NTLM packets to work with this client.


> NTLM authentication against ntlm.herokuapp.com
> --
>
> Key: HTTPCLIENT-1881
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1881
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
>Reporter: Marcel Stör
>Assignee: Karl Wright
>  Labels: authentication, ntlm
> Attachments: HTTPCLIENT-1881.patch, msr-ntlm-prototype.zip
>
>
> I'm prototyping NTLM authentication with your 4.5 HTTP client and Spring 
> RestTemplate. This currently fails with a 
> {{org.apache.http.impl.auth.NTLMEngineException}} "NTLM authentication error: 
> NTLM authentication - buffer too small for data item". 
> The code, wire log (below) and a simple standalone test application 
> (attached) are included.
> h2. Code
> {code:java}
> RestTemplate restTemplate = new RestTemplate();
> restTemplate.setRequestFactory(buildHttpComponentsClientHttpRequestFactory(args));
> private static HttpComponentsClientHttpRequestFactory
> buildHttpComponentsClientHttpRequestFactory(String[] args) {
>   PoolingHttpClientConnectionManager cm = new
> PoolingHttpClientConnectionManager();
>   cm.setMaxTotal(128);
>   cm.setDefaultMaxPerRoute(24);
>   RequestConfig.Builder requestBuilder =
> RequestConfig.custom().setConnectTimeout(5000).setSocketTimeout(1);
>   Registry authSchemeRegistry =
> RegistryBuilder.create()
> .register(AuthSchemes.NTLM, new NTLMSchemeFactory())
> .register(AuthSchemes.SPNEGO, new SPNegoSchemeFactory()).build();
>   CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
>   credentialsProvider.setCredentials(AuthScope.ANY, new
> NTCredentials(args[1], args[2], null, args[3]));
>   HttpClientBuilder builder = HttpClientBuilder.create()
> .setConnectionManager(cm)
> .setDefaultRequestConfig(requestBuilder.build())
> .setDefaultAuthSchemeRegistry(authSchemeRegistry)
> .setDefaultCredentialsProvider(credentialsProvider);
>   return new HttpComponentsClientHttpRequestFactory(builder.build());
> }
> {code}
> h2. Wire log
> {noformat}
> 23:21:22,983 | RestTemplate| Created GET request for 
> "https://ntlm.herokuapp.com;
> 23:21:22,987 | RestTemplate| Setting request Accept 
> header to [text/plain, */*]
> 23:21:22,997 | RequestAddCookies   | CookieSpec selected: 
> default
> 23:21:23,006 | RequestAuthCache| Auth cache not set in 
> the context
> 23:21:23,007 | PoolingHttpClientConnectionManager  | Connection request: 
> [route: {s}->https://ntlm.herokuapp.com:443][total kept alive: 0; route 
> allocated: 0 of 24; total allocated: 0 of 128]
> 23:21:23,029 | PoolingHttpClientConnectionManager  | Connection leased: [id: 
> 0][route: {s}->https://ntlm.herokuapp.com:443][total kept alive: 0; route 
> allocated: 1 of 24; total allocated: 1 of 128]
> 23:21:23,031 | MainClientExec  | Opening connection 
> {s}->https://ntlm.herokuapp.com:443
> 23:21:23,299 | DefaultHttpClientConnectionOperator | Connecting to 
> ntlm.herokuapp.com/54.235.146.123:443
> 23:21:23,299 | SSLConnectionSocketFactory  | Connecting socket to 
> ntlm.herokuapp.com/54.235.146.123:443 with timeout 5000
> 23:21:23,581 | SSLConnectionSocketFactory  | Enabled protocols: 
> [TLSv1, TLSv1.1, TLSv1.2]
> 23:21:23,582 | SSLConnectionSocketFactory  | Enabled cipher 
> suites:[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, 

[jira] [Commented] (HTTPCLIENT-1879) connection should revert to SocketConfig's soTimeout

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1879:
-

Commit 7d16ce5a5a18689398a0dde4de374eda09342dcd in httpcomponents-client's 
branch refs/heads/4.6.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=7d16ce5 
]

HTTPCLIENT-1879: re-apply SocketConfig#socketTimeout to connections leased by 
the pooling and basic connection managers


> connection should revert to SocketConfig's soTimeout
> 
>
> Key: HTTPCLIENT-1879
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1879
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
>Reporter: Xiaoshuang LU
>
> DefaultHttpClientConnectionOperator sets SO_TIMEOUT when creating sockets. 
> However, MainClientExec may overwrite this option in execute method (line 
> 248). It seems that we need to revert this option to the original value 
> before releasing connections.



--
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-1879) connection should revert to SocketConfig's soTimeout

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1879:
-

Commit d6db9ab3d079b44e0a524dacf5e7ce9463618950 in httpcomponents-client's 
branch refs/heads/4.5.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=d6db9ab 
]

HTTPCLIENT-1879: re-apply SocketConfig#socketTimeout to connections leased by 
the pooling and basic connection managers


> connection should revert to SocketConfig's soTimeout
> 
>
> Key: HTTPCLIENT-1879
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1879
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3
>Reporter: Xiaoshuang LU
>
> DefaultHttpClientConnectionOperator sets SO_TIMEOUT when creating sockets. 
> However, MainClientExec may overwrite this option in execute method (line 
> 248). It seems that we need to revert this option to the original value 
> before releasing connections.



--
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] (HTTPCORE-496) Add API org.apache.http.protocol.UriPatternMatcher.entrySet()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279207#comment-16279207
 ] 

ASF subversion and git services commented on HTTPCORE-496:
--

Commit 04c420f9498297d9d4db0892125bab5aa2eae919 in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=04c420f ]

[HTTPCORE-496] Add API
org.apache.http.protocol.UriPatternMatcher.entrySet()

> Add API org.apache.http.protocol.UriPatternMatcher.entrySet()
> -
>
> Key: HTTPCORE-496
> URL: https://issues.apache.org/jira/browse/HTTPCORE-496
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9
>
>
> Add API {{org.apache.http.protocol.UriPatternMatcher.entrySet()}}.



--
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] (HTTPCORE-496) Add API org.apache.http.protocol.UriPatternMatcher.entrySet()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279206#comment-16279206
 ] 

ASF subversion and git services commented on HTTPCORE-496:
--

Commit 276949dd1fbd03cd3b894962ba16bb1e76489ca9 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=276949d ]

[HTTPCORE-496] Add API
org.apache.http.protocol.UriPatternMatcher.entrySet()

> Add API org.apache.http.protocol.UriPatternMatcher.entrySet()
> -
>
> Key: HTTPCORE-496
> URL: https://issues.apache.org/jira/browse/HTTPCORE-496
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9
>
>
> Add API {{org.apache.http.protocol.UriPatternMatcher.entrySet()}}.



--
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] (HTTPCORE-497) Add API Add API org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279294#comment-16279294
 ] 

ASF subversion and git services commented on HTTPCORE-497:
--

Commit 58d72ebd7e496597830fb8d75690207fe66ed95d in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=58d72eb ]

[HTTPCORE-497] Add API Add API
org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher().

> Add API Add API 
> org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher()
> 
>
> Key: HTTPCORE-497
> URL: https://issues.apache.org/jira/browse/HTTPCORE-497
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9
>
>
> Add API 
> org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher().



--
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] (HTTPCORE-496) Add API org.apache.http.protocol.UriPatternMatcher.entrySet()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279848#comment-16279848
 ] 

ASF subversion and git services commented on HTTPCORE-496:
--

Commit ffbe8aae055be99d949455cf296e2e16a2c57b5d in httpcomponents-core's branch 
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=ffbe8aa ]

[HTTPCORE-496] Add API org.apache.http.protocol.UriPatternMatcher.entrySet()


> Add API org.apache.http.protocol.UriPatternMatcher.entrySet()
> -
>
> Key: HTTPCORE-496
> URL: https://issues.apache.org/jira/browse/HTTPCORE-496
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9, 5.0-beta2
>
>
> Add API {{org.apache.http.protocol.UriPatternMatcher.entrySet()}}.



--
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] (HTTPCORE-496) Add API org.apache.http.protocol.UriPatternMatcher.entrySet()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279849#comment-16279849
 ] 

ASF subversion and git services commented on HTTPCORE-496:
--

Commit c81801f8ab0bb404e17d5617e0186c1f72108f9d in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=c81801f ]

[HTTPCORE-496] Fixed synchronization bug


> Add API org.apache.http.protocol.UriPatternMatcher.entrySet()
> -
>
> Key: HTTPCORE-496
> URL: https://issues.apache.org/jira/browse/HTTPCORE-496
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9, 5.0-beta2
>
>
> Add API {{org.apache.http.protocol.UriPatternMatcher.entrySet()}}.



--
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] (HTTPCORE-496) Add API org.apache.http.protocol.UriPatternMatcher.entrySet()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279834#comment-16279834
 ] 

ASF subversion and git services commented on HTTPCORE-496:
--

Commit 21a1bf45faaf4e1ff374439fd79f6ca29e6a84a7 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=21a1bf4 ]

[HTTPCORE-496] Add API org.apache.http.protocol.UriPatternMatcher.entrySet()


> Add API org.apache.http.protocol.UriPatternMatcher.entrySet()
> -
>
> Key: HTTPCORE-496
> URL: https://issues.apache.org/jira/browse/HTTPCORE-496
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9, 5.0-beta2
>
>
> Add API {{org.apache.http.protocol.UriPatternMatcher.entrySet()}}.



--
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] (HTTPCORE-497) Add API Add API org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher()

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279835#comment-16279835
 ] 

ASF subversion and git services commented on HTTPCORE-497:
--

Commit 5c1767a04d77dccacc9de4e038e2feeeb00adca6 in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=5c1767a ]

[HTTPCORE-497] Add API 
org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher()


> Add API Add API 
> org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher()
> 
>
> Key: HTTPCORE-497
> URL: https://issues.apache.org/jira/browse/HTTPCORE-497
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 4.4.9
>
>
> Add API 
> org.apache.http.nio.protocol.UriHttpAsyncRequestHandlerMapper.getUriPatternMatcher().



--
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-1876) Improve the buildString() method in URIBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1876:
-

Commit 2e303b854f88b67d98820bdd9cfdeac01f0ee54e in httpcomponents-client's 
branch refs/heads/4.5.x from aleh_struneuski
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=2e303b8 
]

HTTPCLIENT-1876. Improve the buildString() method in URIBuilder.


> Improve the buildString() method in URIBuilder
> --
>
> Key: HTTPCLIENT-1876
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1876
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4.1
>Reporter: Aleh Struneuski
>Priority: Minor
>
> After building URI using URIBuilder with the setParameters method which has 
> an empty list as argument, the created URI ends with symbol ?.
> String testUrl = "https://test.com/test_path?key=value;;
> URI uri = new 
> URIBuilder(testUrl).clearParameters().setParameters(Arrays.asList()).build();



--
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-1876) Improve the buildString() method in URIBuilder

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1876:
-

Commit 11190331d38f38fc0768c7c8d0ca5a726f910984 in httpcomponents-client's 
branch refs/heads/4.6.x from aleh_struneuski
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=1119033 
]

HTTPCLIENT-1876. Improve the buildString() method in URIBuilder.


> Improve the buildString() method in URIBuilder
> --
>
> Key: HTTPCLIENT-1876
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1876
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4.1
>Reporter: Aleh Struneuski
>Priority: Minor
>
> After building URI using URIBuilder with the setParameters method which has 
> an empty list as argument, the created URI ends with symbol ?.
> String testUrl = "https://test.com/test_path?key=value;;
> URI uri = new 
> URIBuilder(testUrl).clearParameters().setParameters(Arrays.asList()).build();



--
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] (HTTPCORE-524) HTTP 2 Example uses non-existing domain

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470400#comment-16470400
 ] 

ASF subversion and git services commented on HTTPCORE-524:
--

Commit 1d1069eeb102ee3a8ae16929d36588c4ae2761d3 in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=1d1069e ]

HTTPCORE-524: updated examples to use nghttp2.org instead of no longer 
functional http2bin.org


> HTTP 2 Example uses non-existing domain
> ---
>
> Key: HTTPCORE-524
> URL: https://issues.apache.org/jira/browse/HTTPCORE-524
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Reporter: Constantine Plotnikov
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> HTTP 2 example uses non-exiting domain http2bin.org
> [https://hc.apache.org/httpcomponents-core-5.0.x/httpcore5-h2/examples/org/apache/hc/core5/http/examples/Http2RequestExecutionExample.java]
> The sample could not be tried out of the box. On other hand,  HTTP 1.1 Sample 
> uses existing domain and it could be tried out of the box.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-524) HTTP 2 Example uses non-existing domain

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470487#comment-16470487
 ] 

ASF subversion and git services commented on HTTPCORE-524:
--

Commit 74753eb5d8c9e6aded21fe5a9a8c872447ef0e6b in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=74753eb ]

HTTPCORE-524: updated examples to use nghttp2.org instead of no longer 
functional http2bin.org


> HTTP 2 Example uses non-existing domain
> ---
>
> Key: HTTPCORE-524
> URL: https://issues.apache.org/jira/browse/HTTPCORE-524
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Reporter: Constantine Plotnikov
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> HTTP 2 example uses non-exiting domain http2bin.org
> [https://hc.apache.org/httpcomponents-core-5.0.x/httpcore5-h2/examples/org/apache/hc/core5/http/examples/Http2RequestExecutionExample.java]
> The sample could not be tried out of the box. On other hand,  HTTP 1.1 Sample 
> uses existing domain and it could be tried out of the box.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1923) Not properly closing connections in BasicHttpClientConnectionManager

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1923:
-

Commit c300adb4b05e02bd7bff2bfd24d52fa22ae70c1b in httpcomponents-client's 
branch refs/heads/4.6.x from Aleksei Arsenev
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=c300adb 
]

HTTPCLIENT-1923: fixed incorrect connection close on shutdown + fixed 
corresponding test


> Not properly closing connections in BasicHttpClientConnectionManager
> 
>
> Key: HTTPCLIENT-1923
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1923
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.5
>Reporter: Aleksei
>Priority: Minor
>
> Seems we are hitting something similiar to the HTTPCLIENT-1655 issue, where 
> established connections were not properly closed (client sends Reset instead 
> of FIN+ACK)
> We are using
> BasicHttpClientConnectionManager (4.5.5 httpclient version)
> and when we are calling client.close(), we see packet with Reset flag enabled 
> in tcpdump
>  
> Looks like here: 
> [https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/conn/BasicHttpClientConnectionManager.java#L378]
> must be closeConnection()
> [https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/conn/BasicHttpClientConnectionManager.java#L209]
> instead of shutdownConnection
>  
> This issue is not present if we are using PoolingHttpClientConnectionManager
> (in shutdown() there are pool.shutdown:
> [https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/conn/PoolingHttpClientConnectionManager.java#L410]
> where for each entry runs: entry.close(){color:#cc7832} -> 
> this{color}.closeConnection(){color:#cc7832};{color}) - we see normal 
> connection close (FIN+ACK)
>  
> What do you think about it?
> Thank you



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1923) Not properly closing connections in BasicHttpClientConnectionManager

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on HTTPCLIENT-1923:
-

Commit eb27f9ee2946e6aa0741fa089e1188b38fe3c530 in httpcomponents-client's 
branch refs/heads/4.5.x from Aleksei Arsenev
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=eb27f9e 
]

HTTPCLIENT-1923: fixed incorrect connection close on shutdown + fixed 
corresponding test


> Not properly closing connections in BasicHttpClientConnectionManager
> 
>
> Key: HTTPCLIENT-1923
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1923
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.5
>Reporter: Aleksei
>Priority: Minor
>
> Seems we are hitting something similiar to the HTTPCLIENT-1655 issue, where 
> established connections were not properly closed (client sends Reset instead 
> of FIN+ACK)
> We are using
> BasicHttpClientConnectionManager (4.5.5 httpclient version)
> and when we are calling client.close(), we see packet with Reset flag enabled 
> in tcpdump
>  
> Looks like here: 
> [https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/conn/BasicHttpClientConnectionManager.java#L378]
> must be closeConnection()
> [https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/conn/BasicHttpClientConnectionManager.java#L209]
> instead of shutdownConnection
>  
> This issue is not present if we are using PoolingHttpClientConnectionManager
> (in shutdown() there are pool.shutdown:
> [https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/conn/PoolingHttpClientConnectionManager.java#L410]
> where for each entry runs: entry.close(){color:#cc7832} -> 
> this{color}.closeConnection(){color:#cc7832};{color}) - we see normal 
> connection close (FIN+ACK)
>  
> What do you think about it?
> Thank you



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-527) Add remote address when throwing a ConnectException

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16484148#comment-16484148
 ] 

ASF subversion and git services commented on HTTPCORE-527:
--

Commit a02971f5569b0ba00c11049b711014e0caaad0cf in httpcomponents-core's branch 
refs/heads/4.4.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=a02971f ]

[HTTPCORE-527] Add remote address when throwing a ConnectException.
Applied patch from Jason Tedor  with a couple of
changes in messages built for ConnectException (Capitalize the first
letter of the message.)

> Add remote address when throwing a ConnectException
> ---
>
> Key: HTTPCORE-527
> URL: https://issues.apache.org/jira/browse/HTTPCORE-527
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.10
>
>
> PR: https://github.com/apache/httpcomponents-core/pull/64



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-528) Infinite loop on server disconnect

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523668#comment-16523668
 ] 

ASF subversion and git services commented on HTTPCORE-528:
--

Commit c84749a18b255fd23b63700b47bd4bcdae34bb8c in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=c84749a ]

HTTPCORE-528: SSL I/O session spins upon abornal connection closure by the 
opposite endpoint


> Infinite loop on server disconnect
> --
>
> Key: HTTPCORE-528
> URL: https://issues.apache.org/jira/browse/HTTPCORE-528
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.9
> Environment: bare metal Ubuntu 16.04 with kernel 4.4; 
> openjdk1.8.0_172_x64 and Oracle jdk1.8.0_162_x64
> CentOs Docker container with 3.10; openjdk1.8.0_172_x64
> macOS 10.13.5; openjdk1.8.0_172_x64
>Reporter: Hunter Presnall
>Assignee: Oleg Kalnichevski
>Priority: Major
> Attachments: httpdebug.log
>
>
> I am seeing HTTP NIO client get into an infinite loop after the server 
> disconnections the connection. See the log output attached; note some content 
> removed for privacy.
>  
> Note that the HttpAsyncClient has returned the response and the application 
> has completely processed it. The client maintains the connection, as 
> expected, since the response included `Keep-Alive: timeout=5`. Five seconds 
> after everything is complete, the _server_ closes the TCP connection. The 
> client reacts accordingly: the selector wakes up, does a read of -1 bytes, 
> closes the session and sets a 1 second timeout to close the connection in.
>  
> The infinite loop occurs because the selector.select() call _constantly_ 
> returns in AbstractIOReactor.execute()
> readyCount == 1, so events are processed
> processEvent() notes the key is readable and calls:
>   session.resetLastRead()
>   readable(key);
> Because resetLastRead() is constantly updated, the 1 second timeout is never 
> reached and AbstractIOReactor.timeoutCheck() can never call sessionTimedOut() 
> or close the connection.
>  
> Note the entire time this is happening, netstat shows the connection is in 
> CLOSE_WAIT state. The infinite loop continues until the OS keepalive timeout 
> is reached and the connection is cleaned by the OS.
> I am not sure if this epoll / selector behavior is expected or not. However, 
> I have replicated this issue in multiple environments. It seems like the 
> async client should handle this by detecting the condition and closing the 
> connection.
>  
> Other notes from this infinite loop state:
> SSLIOSession.updateEventMask() never closes the session either since the 
> state remains `CLOSING`
> AbstractIODispatch.inputReady() _does not_  read any data from the connection 
> since ssliosession.isAppInputReady() evaluates to false.
> SelectionKeyImpl.interestOps remains 1 (`OP_READ`)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org