[jira] [Comment Edited] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Remko Popma (JIRA)]

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

Remko Popma edited comment on HTTPCLIENT-1664 at 5/3/17 12:22 AM:
--

I'm of the [opinion|http://stackoverflow.com/a/41635246/1446916] that is SLF4J 
showing its age. (I contribute to Log4j2 and I'm biased.)

Key advantage the Log4j2 API is that it allows garbage free logging.  Libraries 
like HttpClient should aim to be garbage free (at least during steady state 
operation).  It would not make sense to pick a logging API that prevents that. 


was (Author: rem...@yahoo.com):
I'm of the [opinion|http://stackoverflow.com/a/41635246/1446916] that is SLF4J 
showing its age. (I contribute to Log4j2 and I'm likely biased.)

Key advantage the Log4j2 API is that it allows garbage free logging.  Libraries 
like HttpClient should aim to be garbage free (at least during steady state 
operation).  It would not make sense to pick a logging API that prevents that. 

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: HttpCore authentication

[Gary Gregory]

Anyone, anyone? https://www.youtube.com/watch?v=uhiCFdWeQfA

;-)

Gary

On Tue, Apr 25, 2017 at 1:32 AM, Gary Gregory 
wrote:

> Hi All,
>
> Has anyone implemented server-side HTTP authentication (basic and digest)
> using HttpCore?
>
> A quick googling has not revealing anything obvious.
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

HttpClient 5, Brotli and Commons Compress

[Gary Gregory]

The upcoming Apache Commons Compress 1.14 will support Brotli decompression.

How should we support this in HttpClient? (I am assuming we would want such
a thing and I am also assuming that using the Commons Compress facade is a
good thing; I might be assuming too much now ! ;-)

Should we have a separate module? Or, should we have the code in
httpclient5 itself with an optional Maven dependency on Commons Compress?

Apps themselves would define which third party library (like Brotli, XZ,
and so on) they end up caring about.

Thoughts?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: HttpClient 5 dependency on log4j2

[Gary Gregory]

Hi Oleg,

I updated the documentation for Log4j 2.

Note that I am unsure on some of the logger names since so much of the
packaging has changed from 4 to 5. In fact, I left most of the logger names
in the JUL example section as is.

Can you review please?

Thank you,
Gary


On Mon, May 1, 2017 at 9:05 AM, Gary Gregory  wrote:

> I'd be happy to.
>
> Gary
>
>
> On May 1, 2017 7:43 AM, "Oleg Kalnichevski"  wrote:
>
> Gary,
>
> I think it should take me another week or two at most to prepare
> HttpClient 5.0a2 and put it on vote.
>
> I anticipate there will likely be a lot of people unhappy about us
> replacing Commons Logging with log4j2 instead of slf4j.
>
> I think it would help a lot to preempt such criticism by preparing a
> document or updating our existing logging guide [1] with a simple
> statement as to why log4j2 has been chosen over slf4j and explaining
> how log4j2 API can act as a logging facade to other logging toolkits
> much like slf4j and how logging appenders could be redirected to slf4j
> APIs.
>
> Would you have some spare cycles to look into that?
>
>
> Oleg
>
> [1] http://hc.apache.org/httpcomponents-client-5.0.x/logging.html
>
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

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

Michael Osipov commented on HTTPCLIENT-1664:


No, I didn't and there was no response to Gary's statement, thus no consent. 
Anyway, I expect someone to check the bug list first before creating new one. 
Especially because Oleg raised the issue on the dev list proposing the same as 
I did a year ago, but I was downvoted back then.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

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

Michael Osipov edited comment on HTTPCLIENT-1664 at 5/2/17 7:11 PM:


Philippe, it's the other way around. I made a proposal, held a discussion, devs 
disagreed, I didn't go futher and let the bug sleep. Now, another dev files an 
issue for his tool of choice, a day later the code is committed. No time for 
review or any further discussion. This is not equal treatment.


was (Author: michael-o):
Philippe, it's the other way around. I made a propopal, held a discussion, devs 
disagreed, I didn't go futher and let the bug sleep. Now, another dev files an 
issue for his tool of choice, a day later the code is committed. No time for 
review or any further discussion. This is not equal treatment.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Philippe Mouawad (JIRA)]

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

Philippe Mouawad commented on HTTPCLIENT-1664:
--

[~michael-o], did you see this thread ?:
https://www.mail-archive.com/dev@hc.apache.org/msg16748.html

Maybe I missed something, but I remember that for this migration it was done 
after some long discussion and Gary worked on it some days.



> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

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

Michael Osipov commented on HTTPCLIENT-1664:


Philippe, it's the other way around. I made a propopal, held a discussion, devs 
disagreed, I didn't go futher and let the bug sleep. Now, another dev files an 
issue for his tool of choice, a day later the code is committed. No time for 
review or any further discussion. This is not equal treatment.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Matt Sicker (JIRA)]

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

Matt Sicker edited comment on HTTPCLIENT-1664 at 5/2/17 7:04 PM:
-

Log4j2 is not just a framework; it's a logging facade. In fact, log4j-api has 
more features than slf4j-api (including custom Message objects, not just 
strings, garbage-free mode, far more unrolled args versions of logging 
messages, Java 8 lambda support, faster markers (though I believe this may have 
been recently fixed in slf4j, though not like many people keep their 
dependencies like that up to date), and many others), and it can log to 
log4j-core, logback, or anything else you want as the API (aka the logging 
facade) is separate from the implementation.

Really, when it comes down to it, log4j-api is objectively better than 
slf4j-api in every way at this point. Both APIs are logging facades that can 
log to whatever backend you want. Also, considering this is an Apache project, 
I'd think that they'd prefer to use other Apache projects as dependencies where 
possible.

Edit: let me also add that please do not use JUL at any cost. Not only is 
configuring it to redirect to your actual logging framework needlessly 
difficult, it is tremendously slow and affects the performance of your library.


was (Author: jvz):
Log4j2 is not just a framework; it's a logging facade. In fact, log4j-api has 
more features than slf4j-api (including custom Message objects, not just 
strings, garbage-free mode, far more unrolled args versions of logging 
messages, Java 8 lambda support, faster markers (though I believe this may have 
been recently fixed in slf4j, though not like many people keep their 
dependencies like that up to date), and many others), and it can log to 
log4j-core, logback, or anything else you want as the API (aka the logging 
facade) is separate from the implementation.

Really, when it comes down to it, log4j-api is objectively better than 
slf4j-api in every way at this point. Both APIs are logging facades that can 
log to whatever backend you want. Also, considering this is an Apache project, 
I'd think that they'd prefer to use other Apache projects as dependencies where 
possible.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Philippe Mouawad (JIRA)]

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

Philippe Mouawad commented on HTTPCLIENT-1664:
--

Hello,
At [~michael-o], I don't think it is a good way to argument by depreciating 
others work.
I don't think what was done is just a matter of sed, and even if it had been, 
it is work which surely took hours.
Besides, AFAIK, Gary contributes other work on the project and on other apache 
projects, such contribution probably done on his personal work SHALL NOT be 
attacked this way, that's not Apache philosophy IMU and not kind.

I am sure you wouldn't  appreciate such consideration of your work on other 
Apache project, I wouldn't appreciate it on my work neither.

Let's be kind with each other and world will be better.

Regards
Philippe

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

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

Michael Osipov edited comment on HTTPCLIENT-1664 at 5/2/17 6:52 PM:


Log4J2 is a personal preference too, isn't it? He even did back his proposal, 
this is it:

bq. Port from Apache Commons Logging to Apache Log4j 2.

and a day later, the issue was fixed w/o further discussion.

What effort actually? Running {{sed}} over the source code? I could have done 
this for SLF4J too two years ago. What Gary did is imposing his preferred 
logging implementation which I never did. I just wanted to update the logging 
facade to something modern.


was (Author: michael-o):
Log4J2 is a personal preference too, isn't it? He even did back his proposal, 
this is it:

bq. Port from Apache Commons Logging to Apache Log4j 2.

What effort actually? Running {{sed}} over the source code? I could have done 
this for SLF4J too two years ago. What Gary did is imposing his preferred 
logging implementation which I never did. I just wanted to update the logging 
facade to something modern.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] httpclient pull request #75: Add Brotli support

[pmouawad]

Github user pmouawad closed the pull request at:

https://github.com/apache/httpclient/pull/75


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] httpclient issue #75: Add Brotli support

[pmouawad]

Github user pmouawad commented on the issue:

https://github.com/apache/httpclient/pull/75
  
Hello,
As advised by Oleg and Gary, I opened a PR towards commons-compress.

Regards


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Comment Edited] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

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

Michael Osipov edited comment on HTTPCLIENT-1664 at 5/2/17 6:50 PM:


Log4J2 is a personal preference too, isn't it? He even did back his proposal, 
this is it:

bq. Port from Apache Commons Logging to Apache Log4j 2.

What effort actually? Running {{sed}} over the source code? I could have done 
this for SLF4J too two years ago. What Gary did is imposing his preferred 
logging implementation which I never did. I just wanted to update the logging 
facade to something modern.


was (Author: michael-o):
Log4J2 is a personal preference too, isn't it? He even did back his proposal, 
this is it:

bq. Port from Apache Commons Logging to Apache Log4j 2.

What effort actually? Running {{sed}} over the source code? I could have done 
this for SLF4J too two years ago. What Gary did is imposing his preferred 
logging implementation which I never did. I just wanted to update the logging 
facade to something new.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

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

Michael Osipov commented on HTTPCLIENT-1664:


Log4J2 is a personal preference too, isn't it? He even did back his proposal, 
this is it:

bq. Port from Apache Commons Logging to Apache Log4j 2.

What effort actually? Running {{sed}} over the source code? I could have done 
this for SLF4J too two years ago. What Gary did is imposing his preferred 
logging implementation which I never did. I just wanted to update the logging 
facade to something new.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Oleg Kalnichevski (JIRA)]

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

Oleg Kalnichevski commented on HTTPCLIENT-1664:
---

bq. Seriously, I don't see how this has been resolved. 

[~michael-o] I am not sure what kind of resolution you expect. You have been 
asked to back your proposal with something other than your personal preferences 
but you refused. I do not necessarily agree with [~garydgregory] but at the 
very least he was willing to put effort into it and I respect that.

bq. Use of this adapter may cause some loss of performance

This sounds like a problem with the SLF4J adapter and not the Log4j 2 API per 
se.

Oleg

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

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

Michael Osipov edited comment on HTTPCLIENT-1664 at 5/2/17 4:08 PM:


Seriously, I don't see how this has been resolved. It has been migrated away 
from Commons Logging to Log4J2. You now need another a shim for SLF4J. So this 
issue has not been fixed anyhow.

[~garydgregory], why didn't you put any comment on this issue?

And here is the first problem with the new shim:

bq. The Log4j 2 to SLF4J Adapter allows applications coded to the Log4j 2 API 
to be routed to SLF4J. Use of this adapter may cause some loss of performance 
as the Log4j 2 Messages must be formatted before they can be passed to SLF4J. 
With Log4j 2 as the implementation these would normally be formatted only when 
they are accessed by a Filter or Appender.

What do we actually gain then? Nothing, Commons Logging did very much the same.


was (Author: michael-o):
Seriously, I don't see how this has been resolved. It has been migrated away 
from Commons Logging to Log4J2. You now need another a shim for SLF4J. So this 
issue has not been fixed anyhow.

[~garydgregory], why didn't you put any comment on this issue?

And here is the first problem with the new shim:

bq. The Log4j 2 to SLF4J Adapter allows applications coded to the Log4j 2 API 
to be routed to SLF4J. Use of this adapter may cause some loss of performance 
as the Log4j 2 Messages must be formatted before they can be passed to SLF4J. 
With Log4j 2 as the implementation these would normally be formatted only when 
they are accessed by a Filter or Appender.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Reopened] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Michael Osipov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reopened HTTPCLIENT-1664:


Seriously, I don't see how this has been resolved. It has been migrated away 
from Commons Logging to Log4J2. You now need another a shim for SLF4J. So this 
issue has not been fixed anyhow.

[~garydgregory], why didn't you put any comment on this issue?

And here is the first problem with the new shim:

bq. The Log4j 2 to SLF4J Adapter allows applications coded to the Log4j 2 API 
to be routed to SLF4J. Use of this adapter may cause some loss of performance 
as the Log4j 2 Messages must be formatted before they can be passed to SLF4J. 
With Log4j 2 as the implementation these would normally be formatted only when 
they are accessed by a Filter or Appender.

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1787) OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri

[Julian Sedding (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved HTTPCLIENT-1787.

Resolution: Cannot Reproduce

Closing this as there was no reply to clarify the issue.

> OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri
> --
>
> Key: HTTPCLIENT-1787
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1787
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
> Environment: OSGi
>Reporter: Srijan Bhatnagar
>Assignee: Julian Sedding
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> OSGiHttpRoutePlanner seems to always set the "http" scheme for the proxy-ed 
> host instead of figuring it out from the original url.
> It should leverage target scheme while building proxy-ed uri.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1724) Support getConnectionManager() on HttpAsyncClient.class

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1724:
--
Fix Version/s: (was: 5.0)
   5.0 Alpha2

> Support getConnectionManager() on HttpAsyncClient.class
> ---
>
> Key: HTTPCLIENT-1724
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1724
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Kalyanaraman Santhanam
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> When the HttpAsyncClient is initialized using the Builder as follows:
> HttpAsyncClients.custom()
> .build();
> ConnectionManager is initialized to nice set of defaults. 
> `https://github.com/apache/httpasyncclient/blob/4.1.x/httpasyncclient/src/main/java/org/apache/http/impl/nio/client/HttpAsyncClientBuilder.java#L647`
> However, the absence of getConnectionManager(), forces anyone who is 
> interested in collecting the http stats need to initialize the 
> ConnectionManager themselves. 
> Which means a developer like is just going to grab the code from the 
> `HttpAsyncClientBuilder` and add it my code. This defeats the purpose of 
> having a `HttpAsyncClientBuilder` and prevents code reusability.
> So I want to know if there is a way to either expose the ConnectionManager or 
> expose the Stats of the ConnectionManager.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1821) Syncronous and asynchronous versions of the client report exception in a slightly different way

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1821.
---
Resolution: Won't Fix

> Syncronous and asynchronous versions of the client report exception in a 
> slightly different way
> ---
>
> Key: HTTPCLIENT-1821
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1821
> Project: HttpComponents HttpClient
>  Issue Type: Task
>Reporter: Sebastiano Vigna
>Priority: Minor
> Fix For: 5.0
>
>
> This is more a "surprising behaviour" report than a true bug report. We 
> noticed that if you use the asynchronous client and perform too many 
> redirects, the exception passed to the FutureCallback is a RedirectException. 
> However, if you use the synchronous client the execute() method throws a 
> ClientProtocolException whose cause is a RedirectException. If this behaviour 
> is intended it should be probably documented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1691) Wouldn't it be better if the Fluent Executor set useSystemProperties on its HttpClient?

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1691:
--
Fix Version/s: (was: 5.0)
   5.0 Alpha2

> Wouldn't it be better if the Fluent Executor set useSystemProperties on its 
> HttpClient?
> ---
>
> Key: HTTPCLIENT-1691
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1691
> Project: HttpComponents HttpClient
>  Issue Type: Wish
>  Components: Fluent HC
>Affects Versions: 4.5
>Reporter: Andrew Garrett
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Is the fact that the Fluent Executor does not call useSystemProperties when 
> building its HttpClient a design decision? This is quite painful as it 
> requires us to fork a library we are using, which in turn uses the Fluent 
> client, in order to get it to accept proxy settings by manually adding the 
> proxy. Every other library that our application uses respects http.proxyHost 
> and http.proxyPort, so this is pretty unfortunate. If not using the system 
> properties was not a design decision, can we change the Fluent Executor to 
> use them?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1656) Client Builder doesn't expose setValidateAfterInactivity(int)

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1656:
--
Fix Version/s: (was: 5.0)
   5.0 Alpha2

> Client Builder doesn't expose setValidateAfterInactivity(int)
> -
>
> Key: HTTPCLIENT-1656
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1656
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4.1
>Reporter: yair ogen
>Assignee: Oleg Kalnichevski
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> The API 'setStaleConnectionCheckEnabled' on the RequestConfig Builder is 
> deprecated. It points to calling 'setValidateAfterInactivity' on the 
> PoolingHttpClientConnectionManager class. 
> However we shouldn't mandate creating our own 
> PoolingHttpClientConnectionManager instance (instead of reusing the one 
> created automatically by the httpClient builder) just to 
> setValidateAfterInactivity.
> We should expose on the client/request config builder a 
> setValidateAfterInactivity like we do for 'setMaxConnPerRoute' and 
> 'setMaxConnTotal' (which in the builder are later set on the internally 
> created PoolingHttpClientConnectionManager ).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1795) Http Client does not support RFC-compliant quoted IPv6 Link-Local host literals

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1795:
--
Fix Version/s: (was: 5.0)
   5.0 Alpha2

> Http Client does not support RFC-compliant quoted IPv6 Link-Local host 
> literals
> ---
>
> Key: HTTPCLIENT-1795
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1795
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 4.5.2
>Reporter: Andreas Wundsam
> Fix For: 5.0 Alpha2
>
>
> [RFC 6874|https://tools.ietf.org/html/rfc6874] states that, when constructing 
> a URL with an LLv6 literal, the {{%}} sign that prefixes the ZoneID must be 
> quoted as {{%25}}. E.g., the LLv6 address 
> {{fe80::221:b7ff:fe8a:57d5%en4}} should be specified as 
> {{scheme://[fe80::221:b7ff:fe8a:57d5%25en4]/...}} in a URL.
> httpclient does not seem to support quoted host literals:
> Example:
> {code}
> Request.Get("http://[fe80::221:b7ff:fe8a:57d5%25en4]/;)
> .connectTimeout(1000)
> .socketTimeout(1000)
> .execute().returnContent().asString();
> {code}
> results in
> {noformat}
> java.net.UnknownHostException: no such interface 25en4
>   at java.net.Inet6Address.initstr(Inet6Address.java:487)
>   at java.net.Inet6Address.(Inet6Address.java:408)
>   at java.net.InetAddress.getAllByName(InetAddress.java:1181)
>   at java.net.InetAddress.getAllByName(InetAddress.java:1126)
>   at 
> org.apache.http.impl.conn.SystemDefaultDnsResolver.resolve(SystemDefaultDnsResolver.java:45)
>   at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:111)
>   at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
>   at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
>   at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
>   at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
>   at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>   at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
>   at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>   at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>   at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>   at 
> org.apache.http.client.fluent.Request.internalExecute(Request.java:173)
>   at org.apache.http.client.fluent.Request.execute(Request.java:177)
>   at Test.name(Test.java:12)
> [...]
> {noformat}
> It appears that httpclient directly passes the host literal 
> {{[fe80::221:b7ff:fe8a:57d5%25en4]}} to the Java standard method 
> {{InetAddress.getAllByName(host)}}, which does not support the URL quoting 
> that RFC 6874 prescribes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1826) Async Builder should include setting am ExecutorService

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1826:
--
Fix Version/s: (was: 5.0)
   5.0 Alpha2

> Async Builder should include setting am ExecutorService
> ---
>
> Key: HTTPCLIENT-1826
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1826
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: yair ogen
> Fix For: 5.0 Alpha2
>
>
> Currently you only expose setting ThreadFactory. Not very useful if a user 
> wants to send in a different thread pool altogether.
> We must have an option to pass in thread pools especially if we want this 
> async work to co-exist in the same pool as other tasks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1818) Add support for interceptors to the internal Async IO Threas

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1818:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: 5.0)
   Stuck

> Add support for interceptors to the internal Async IO Threas
> 
>
> Key: HTTPCLIENT-1818
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1818
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>Reporter: yair ogen
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> I have a requirement to attach all logs with a transaction id. I set this ID 
> in Log4j MDC, but I need a way to intercept the request in a way I can set 
> this MDC key in the internal thread pools used by the async client.
> The current interceptors are run before the IO thread pool starts to run,



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1580) Deprecate NTCredentials constructor with workstation parameter

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1580:
--
Fix Version/s: (was: 5.0)
   5.0 Alpha2

> Deprecate NTCredentials constructor with workstation parameter
> --
>
> Key: HTTPCLIENT-1580
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1580
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>Reporter: Michael Osipov
> Fix For: 5.0 Alpha2
>
>
> The underlying NTLM implemntation shall determine the localname of the 
> current workstation at runtime/request time. There is no need to supply this 
> information. Other popular implementation do not provide this attribute 
> either, e.g., curl.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1780) [OSGi] ProxyConfiguration is mutable but not thread-safe

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1780:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: Stuck

> [OSGi] ProxyConfiguration is mutable but not thread-safe
> 
>
> Key: HTTPCLIENT-1780
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1780
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.0 Alpha1
>Reporter: Julian Sedding
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> {{ProxyConfiguration}} objects can be updated while being used by other 
> threads.
> The update of a {{ProxyConfiguration}} should be atomic and the changes 
> visible to other threads immediately after the update.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1813) [OSGi] ServiceRegistration properties of OSGiProxyConfiguration not updated

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1813:
--
   Labels: osgi stuck volunteers-wanted  (was: osgi)
Fix Version/s: Stuck

> [OSGi] ServiceRegistration properties of OSGiProxyConfiguration not updated
> ---
>
> Key: HTTPCLIENT-1813
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1813
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.3, 5.0 Alpha1
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
>  Labels: osgi, stuck, volunteers-wanted
> Fix For: Stuck
>
>
> The ServiceRegistration properties of the OSGiProxyConfiguration service are 
> not updated on configuration changes. This has no functional impact, as the 
> OSGiProxyConfiguration instance is updated, however reporting tools such as 
> the Felix webconsole may indicate erroneous (old) information.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1781) [OSGi] OSGiTrustedHostsConfiguration is mutable but not thread-safe

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1781:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: Stuck

> [OSGi] OSGiTrustedHostsConfiguration is mutable but not thread-safe
> ---
>
> Key: HTTPCLIENT-1781
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1781
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 5.0 Alpha1
>Reporter: Julian Sedding
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> {{OSGiTrustedHostsConfiguration}} objects can be updated while being used by 
> other threads.
> The update of a {{OSGiTrustedHostsConfiguration}} should be atomic and the 
> changes visible to other threads immediately after the update.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1827) Provide caching for streamed HTTP exchanges in CachingHttpAsyncClient

[Oleg Kalnichevski (JIRA)]

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

Oleg Kalnichevski updated HTTPCLIENT-1827:
--
Fix Version/s: 5.0

> 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.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1787) OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1787:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: Stuck

> OSGiHttpRoutePlanner should leverage target scheme while building proxy-ed uri
> --
>
> Key: HTTPCLIENT-1787
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1787
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2
> Environment: OSGi
>Reporter: Srijan Bhatnagar
>Assignee: Julian Sedding
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> OSGiHttpRoutePlanner seems to always set the "http" scheme for the proxy-ed 
> host instead of figuring it out from the original url.
> It should leverage target scheme while building proxy-ed uri.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1725) Heuristic caching does not work for URIs with a query string

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1725:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: Stuck

> Heuristic caching does not work for URIs with a query string
> 
>
> Key: HTTPCLIENT-1725
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1725
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 4.5.1
>Reporter: Charlie Halford
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
> Attachments: HTTPCLIENT-1725_add_query_string_caching.diff
>
>
> When enabling heuristic caching and setting a default lifetime, the responses 
> from the server I am requesting from are not being stored in the cache.
> In org.apache.http.impl.client.cache.ResponseCachingPolicy, line 250 
> determines if the URI contains a query string:
> {code}
> request.getRequestLine().getUri().contains("?")
> {code}
> A few lines below, it then checks to see if the response contains cache 
> headers:
> {code}
> else if (!isExplicitlyCacheable(response))
> {code}
> As I am attempting to cache a response that I know does not contain cache 
> headers, the response should succeed in being cached. However, it fails the 
> isExplictlyCachable() check, and thus returns false to the overall 
> isResponseCachable() method. The isExplicitlyCachable() method is checked 
> later on in the stack, so perhaps it can be safely removed here?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1775) [OSGi] Proxy Configuration PID changed between 4.x and 5.x branches

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1775:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: Stuck

> [OSGi] Proxy Configuration PID changed between 4.x and 5.x branches
> ---
>
> Key: HTTPCLIENT-1775
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1775
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.0 Alpha1
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> The PID for the OSGi Proxy Configuration was changed between 4.x and 5.x.
> As the PID is just an opaque string, there is no need to break existing proxy 
> configurations with the update from 4.x to 5.x. Hence I suggest to revert the 
> PID to its previous value.
> Also, to stay consistent in the naming, I would change/revert the other PIDs 
> to start with "org.apache.http."
> WDYT, [~simone.tripodi]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1806) Add a route inteceptor

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1806.
---
   Resolution: Fixed
Fix Version/s: (was: 5.0)
   5.0 Alpha2

Baosen,

Please have a look at the new exec request interceptor APIs in SVN trunk. I 
hope this is what you actually want.

Classic (blocking)
https://github.com/apache/httpclient/blob/trunk/httpclient5/src/examples/org/apache/hc/client5/http/examples/ClientInterceptors.java

Async
https://github.com/apache/httpclient/blob/trunk/httpclient5/src/examples/org/apache/hc/client5/http/examples/AsyncClientInterceptors.java

Oleg

> Add a route inteceptor
> --
>
> Key: HTTPCLIENT-1806
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1806
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async), HttpClient (classic)
>Reporter: Baosen Cui
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> I had meet a problem that I need to log the time cost by  method 
> “establishRoute”( in httpclient ).
> Since there seems nothing to support, I wrote a interceptor into HttpCore 
> coping the structure of “HttpProcessor"
> Would this be accepted? Or there has already something alike?
> @ThreadSafe // provided injected dependencies are immutable
> public final class ImmutableRouteProcessor implements RouteProcessor {
> ...
> }
> public interface PostRouteInterceptor {
>   void postProcess(final HttpRequest request, final HttpContext context);
> }
> public interface PreRouteInterceptor {
>   void preProcess(final HttpRequest request, final HttpContext context);
> }
> public interface RouteProcessor extends PreRouteInterceptor, 
> PostRouteInterceptor {
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1378) CacheableRequestPolicy and ResponseCachingPolicy Have Overlapping Functionality

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1378:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: Future)
   Stuck

> CacheableRequestPolicy and ResponseCachingPolicy Have Overlapping 
> Functionality
> ---
>
> Key: HTTPCLIENT-1378
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1378
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.3 Beta2
>Reporter: James Leigh
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> As discussed in HTTPCLIENT-1370, both classes check the same thing in the 
> request object for cache-ability, but handle edge cases differently. The 
> repeated code should be removed and either CacheableRequestPolicy injected as 
> a dependency into the ResponseCachingPolicy or the two classes should be 
> merged into a single class.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1664.
---
   Resolution: Fixed
Fix Version/s: (was: Future)
   5.0 Alpha2

For better or worse HttpClient 5.0 has been migrated to Log4j2 APIs, which can 
use various back-ends besides its native one and redirect logging to JUL, and 
SLF4J.

Oleg

> Migrate away from Commons Logging to SLF4J
> --
>
> Key: HTTPCLIENT-1664
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1664
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Michael Osipov
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Commons Log is old and has several serious issue. HttpClient 5.0 should 
> completely migrate away from it. SLF4J is an extremely wide support logging 
> facade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1713) Certain responses from a POST should be cacheable

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1713:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: Future)
   Stuck

> Certain responses from a POST should be cacheable
> -
>
> Key: HTTPCLIENT-1713
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1713
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Reporter: Brian Chang
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> In {{ResponseCachingPolicy}}, only {{GET}} and {{HEAD}} methods are 
> cacheable. However, according to RFC 2616 
> [https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5] a {{POST}} 
> may be cacheable.
> The exact circumstances are better detailed here:
> [http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#section-2.3.4]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1375) Add context attribute when request are processed by an AsynchronousValidator

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1375.
---
   Resolution: Won't Fix
Fix Version/s: (was: Future)

> Add context attribute when request are processed by an AsynchronousValidator 
> -
>
> Key: HTTPCLIENT-1375
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1375
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.2.5, 4.3 Beta2
>Reporter: Nicolas Richeton
>Priority: Minor
>
> With the current code, it seems to be no way to know if a request is being 
> processed as a normal request, or if it is being processed by an 
> AsynchronousValidator. 
> Our use case is : 
> - CachingHttpClient is used in a web app.
> - We use a custom cookie store to store cookies in user session (other 
> usecases could be access to session/response objects while processing the 
> request, custom code between CachingHttpClient and HttpClient). 
> - We use background revalidation. 
> - If the backend returns a cookie during revalidation, we have no longer 
> access to the session so we want to ignore the cookie and prevent calls on 
> session object. 
> But we cannot identify the asynchronous request since it is the same as a 
> synchronous one. 
> A possible solution could be to add an attribute to the request context in 
> AsynchronousValidationRequest constructor, something like : 
> context.setAttribute( "asyncRequest", "true");



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1368) stale-if-error request cache directive should also apply to non-revalidatable cache entries

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1368:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: Future)
   Stuck

> stale-if-error request cache directive should also apply to non-revalidatable 
> cache entries
> ---
>
> Key: HTTPCLIENT-1368
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1368
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.2.4, 4.2.5, 4.3 Beta1
>Reporter: Jon Moore
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> The stale-if-error request cache directive is defined in RFC 5861:
> http://tools.ietf.org/html/rfc5861
> As implemented, this will only apply to cache entries that are revalidatable 
> (i.e. they have an Etag or Last-Modified header and can be refreshed with a 
> conditional request) but it should also apply to any stale cache entry.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1099) Overriding Caching Policies

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1099:
--
   Labels: cache policy stuck volunteers-wanted  (was: cache policy)
Fix Version/s: (was: Future)
   Stuck

> Overriding Caching Policies
> ---
>
> Key: HTTPCLIENT-1099
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1099
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.1.1
>Reporter: Bart Robeyns
>Assignee: Jon Moore
>Priority: Minor
>  Labels: cache, policy, stuck, volunteers-wanted
> Fix For: Stuck
>
> Attachments: OpenPolicies.patch
>
>
> It is not possible to alter the behaviour of the CachingHttpClient because 
> the policies defining the behaviour are private and tied directly to specific 
> implementations in the CachingHttpClients constructor. Furthermore, these 
> policies are package private, discouraging reuse and/or extensions.
> Making this possible is easy enough (provide some policy-setters or 
> -constructor-args in CachingHttpClient and make the policy-classes public); 
> the attached patch allows custom Policies, extending the default ones to be 
> set on the CacheConfig class.
> The specific case that led to this question:
> A back-end application only sets its Content-Length header for responses 
> below 8K. This response does get stored in the cache, but when retrieving it 
> from the cache, CacheValidityPolicy.contentLengthHeaderMatchesActualLength 
> checks the Content-Length header with the stored size (to verify whether the 
> cached content is complete). This check fails, causing the cache entry to be 
> deemed unusable. If we were able to provide our own subclassed 
> CacheValidityPolicy, it would be easy to skip the check if the header is 
> missing and thus accomodate this specific back-end quirk.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1395) Call the storage implementation only once on a cache miss

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1395:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: 5.0)
   Stuck

> Call the storage implementation only once on a cache miss
> -
>
> Key: HTTPCLIENT-1395
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1395
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.2.5
>Reporter: Nikola Petrov
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
> Attachments: call-storage-implementation-once-4.2-branch.patch, 
> call-storage-implementation-once.patch, 
> call-storage-implementation-once-trunk.patch
>
>
> I am trying to use the httpclient-cache component with a Cassandra backend. 
> Everything seems good except that HttpCacheStorage#getEntry is getting called 
> 3 times the first time resulting in a performance bottleneck. There might be 
> a way to handle this in the Storage implementation by caching the recently 
> queried values but I think that a better place is in the CachingHttpClient 
> class. The current code expects zero latency to the storage backend(the 
> current implementations are all memory based) but here is a patch that fixes 
> the problem. Some notes:
> * I am using the code from the 4.2.5 release(but can port the code to the 
> current trunk) 
> * test is provided in org.apache.http.impl.client.cache.TestCachingHttpClient
> * BasicHttpCache is patched to expose methods that check if the key is found 
> or if a proper variant is found - without this there is no way to say if 
> there was a real cache miss or the specific variant is missing
> * CachingHttpClient is checking if the current HttpCache implementation is 
> BasicHttpCache so it can use the new methods - I didn't want to change the 
> interface because this will add breaking changes to the API
> * This exposes the alreadyHaveNewerCacheEntry method so implementations can 
> control if the client should check for a more recent version in the cache



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-973) Websocket support

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-973:
-
Labels: volunteers-wanted  (was: )

> Websocket support
> -
>
> Key: HTTPCLIENT-973
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-973
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (classic)
>Reporter: Erik Martino Hansen
>  Labels: volunteers-wanted
> Fix For: Future
>
>
> Websocket are designed for browser use but I see useful use cases in a java 
> client as well:
> - java clients for existing websites where changes are pushed to clients 
> using websockets
> - use of websockets to tunnel through firewalls
> - put all communication behind single port on servlet engine.
> A good example on emerging use is websocket+stomp 
> (http://jmesnil.net/stomp-websocket/doc/, 
> http://www.nighttale.net/activemq/activemq-54-stomp-over-web-sockets.html)
> so I believe hc should support websocket clients.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1819) org.apache.http.impl.client.DecompressingHttpClient should have an nio counterpart: DecompressingHttpAsyncClient

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1819.
---
   Resolution: Duplicate
Fix Version/s: (was: 5.0)

> org.apache.http.impl.client.DecompressingHttpClient should have an nio 
> counterpart: DecompressingHttpAsyncClient
> 
>
> Key: HTTPCLIENT-1819
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1819
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>Reporter: Clinton Nielsen
> Attachments: DecompressingHttpAsyncClient.java
>
>
> org.apache.http.impl.client.DecompressingHttpClient should have an nio 
> counterpart: DecompressingHttpAsyncClient. 
> Since I needed the functionality for my own project, I went ahead and made 
> the appropriate changes to DecompressingHttpClient to allow it to decorate an 
> HttpAsyncClient. 
> I'm attaching the files here, for consideration for a future release.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1825) CachingHttpAsyncClient does not follow same pattern as Caching HttpClient

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1825:
--
Labels: volunteers-wanted  (was: )

Proper async caching can now be implemented using the new async request exec 
interceptor API. Volunteers welcome.

https://github.com/apache/httpclient/blob/trunk/httpclient5/src/examples/org/apache/hc/client5/http/examples/AsyncClientInterceptors.java

Oleg

> CachingHttpAsyncClient does not follow same pattern as Caching HttpClient 
> --
>
> Key: HTTPCLIENT-1825
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1825
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: Matt Inger
>  Labels: volunteers-wanted
> Fix For: 5.0
>
>
> I would have expected the Caching version of the HttpAsyncClient library to 
> following same pattern as the non async version.  In the non-async version, 
> we have a CachingHttpClientBuilder class which extends the HttpClientBuilder, 
> and they both end up returning the same client implementation:  
> CloseableHttpClient.  
> I would have expected the same from the async version.  Instead it uses 
> CachingHttpAsyncClient as a decorator approach.
> This is unfortunate, because i really want to be able to not care about the 
> implementation and do this:
> CloseableHttpAysncClient client = clientFactory.create("test");
> But i cannot do this, due to the design.  I also considered this:
> HttpAysncClient client = clientFactory.create("test");
> But this does not guarantee that it implements Closeable, and in fact, 
> CachingHttpAsyncClient does not implement that interface.
> I'd like to see it more in line with the synchronous version.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1822) Support for transparent content decompression

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1822:
--
Labels: decopression httpprocessor volunteers-wanted  (was: decopression 
httpprocessor)

Transparent content decompression can now be implemented using the new async 
request exec interceptor API. Volunteers welcome.

https://github.com/apache/httpclient/blob/trunk/httpclient5/src/examples/org/apache/hc/client5/http/examples/AsyncClientMessageTrailers.java

Oleg 

> Support for transparent content decompression
> -
>
> Key: HTTPCLIENT-1822
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1822
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: clajder
>  Labels: decopression, httpprocessor, volunteers-wanted
> Fix For: 5.0
>
>
> Created http processor array like this 
>HttpProcessor httpproc = HttpProcessorBuilder.create()
>   .add(new RequestDefaultHeaders())
>   .add(new RequestAcceptEncoding())
>   .add(new RequestClientConnControl())
>   .add(new RequestContent())
>   .add(new ResponseContentEncoding())
>   .add(new RequestTargetHost()).build();
>
> later http async client constructed as follows
> CloseableHttpAsyncClient httpclient = HttpAsyncClients.custom()
> .setConnectionManager(connManager)
> .setHttpProcessor(httpproc)
> .setUserAgent(hc.getUserAgent())
> .setDefaultRequestConfig(defaultRequestConfig)
> .build();
> during invocation
> Future future = httpclient .execute(httpget, null);
> HttpResponse response = future.get();
> entity.getContent() is not decompressed (gzip), however 
> ResponseContentEncoding http processor was executed



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1823) HttpRequestInterceptor and HttpResponseInterceptor don't allow entity manipulation

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1823.
---
   Resolution: Fixed
Fix Version/s: (was: 5.0)
   5.0 Alpha2

Async message entity content manipulation should be possible as of 5.0a2. See 
examples:  

https://github.com/apache/httpclient/blob/trunk/httpclient5/src/examples/org/apache/hc/client5/http/examples/AsyncClientInterceptors.java
https://github.com/apache/httpclient/blob/trunk/httpclient5/src/examples/org/apache/hc/client5/http/examples/AsyncClientMessageTrailers.java

Oleg

> HttpRequestInterceptor and HttpResponseInterceptor don't allow entity 
> manipulation
> --
>
> Key: HTTPCLIENT-1823
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1823
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: Sven Zethelius
> Fix For: 5.0 Alpha2
>
>
> Examples show how to do GZIP compression in sync HttpClient ( 
> https://hc.apache.org/httpcomponents-client-4.2.x/httpclient/examples/org/apache/http/examples/client/ClientGZipContentCompression.java),
>  but even thought AsyncHttpClient supports registering the same 
> HttpRequestInterceptor and HttpResponseInterceptor they can only modify the 
> headers.  Doing any modification of the entity, which is necessary to do 
> compression ends up being ignored.  
> In HttpRequestInterceptor, this is because A) BasicAsyncRequestProducer is 
> registerd early in the lifecycle with a reference to the original request 
> entity which it uses to write the content.  B) The wrapping request entity 
> passed to the interceptor doesn't pass calls to setEntity back to the request 
> it's wrapping.
> In HttpResponseInterceptor, the entity of the HttpResponse is bypassed 
> completely by BasicAsyncResponseConsumer.
> This means clients of AsyncHttpClient have no way to intercept the message.
> My request is that there needs to be a way to intercept and manipulate the 
> request bytes in/out so that compression can be implemented.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1439) Infinite timeout on entity send

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1439.
---
   Resolution: Won't Fix
Fix Version/s: (was: Future)

> Infinite timeout on entity send
> ---
>
> Key: HTTPCLIENT-1439
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1439
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.3.1
>Reporter: Dmitry Potapov
>Priority: Minor
>
> Steps to reproduce:
> 1. Create HttpClient with RequestConfig.setSocketTimeout(1000)
> 2. Create ByteArrayEntity with 10 MB entity (entity size must be greater that 
> default socket send/receive buffer size)
> 3. Create ServerSocket and bind it to any port
> 4. Try to send HttpPost to this port with aforementioned entity
> Expected result:
> SocketTimeoutException is raised after 1 second since request start
> Actual result:
> Request send hangs
> Root cause:
> According to javadocs Socket.setSoTimeout() affects only .read() operations 
> and nothing said about write operations. While client tries to send data to 
> the remote port it receives TCP ZeroWindow messages in return, so formally 
> connection is still alive and won't be closed by system.
> Possible solution:
> 1. Start daemon thread somewhere in PoolingHttpClientManager which will 
> perform monitoring of all connections in this pool (say, once per 100 ms)
> 2. Each time new connection created, register it in monitoring thread object
> 3. Each time SessionInputBufferImpl enters .write() function, set connection 
> state to WRITE (and set it to IDLE in finally section)
> 4. Monitoring thread will iterate over all known connections and if 
> connection state is WRITE then compare state timestamp and current time. If 
> difference is more than timeout then close socket
> I've prepared small test which demonstrates the problem. HttpAsyncClient is 
> not affected by this issue (because reactor threads already works as 
> monitoring threads).
> import java.net.ServerSocket;
> import org.apache.http.concurrent.FutureCallback;
> import org.apache.http.config.SocketConfig;
> import org.apache.http.client.config.RequestConfig;
> import org.apache.http.client.methods.HttpPost;
> import org.apache.http.entity.ByteArrayEntity;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> import org.apache.http.impl.nio.client.CloseableHttpAsyncClient;
> import org.apache.http.impl.nio.client.HttpAsyncClients;
> import org.apache.http.nio.entity.NByteArrayEntity;
> public class Main {
> public static void main(final String[] args) throws Exception {
> ServerSocket socket = new ServerSocket(0);
> System.out.println("Listening port " + socket.getLocalPort());
> CloseableHttpAsyncClient client = HttpAsyncClients.custom()
> .setDefaultRequestConfig(RequestConfig.custom()
> .setSocketTimeout(1000)
> .build())
> .build();
> client.start();
> HttpPost post = new HttpPost("http://localhost:; + 
> socket.getLocalPort());
> post.setEntity(new NByteArrayEntity(new byte[1000]));
> System.out.println("Sending request");
> client.execute(post, new FutureCallback() {
> public void cancelled() {
> }
> public void completed(final HttpResponse response) {
> }
> public void failed(final Exception e) {
> System.out.println("Request failed: " + e);
> }
> });
> Thread.sleep(2000);
> CloseableHttpClient client2 = HttpClients.custom()
> .setDefaultRequestConfig(RequestConfig.custom()
> .setSocketTimeout(1000)
> .build())
> .build();
> post.setEntity(new ByteArrayEntity(new byte[1000]));
> System.out.println("\nSending second request");
> try {
> client2.execute(post);
> } catch (Exception e) {
> System.out.println("Exception caught on second request");
> }
> System.out.println("Second request executed");
> }
> }
> I'm not sure that solution suggested is acceptable.
> Also I'm not sure that I'll have enough time to provide this solution by 
> myself in this year.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Moved] (HTTPCORE-459) Make request available to ResponseHandlers

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski moved HTTPCLIENT-1757 to HTTPCORE-459:


Fix Version/s: (was: 5.0 Alpha2)
   5.0-alpha4
Affects Version/s: (was: 4.5.2)
   5.0-alpha3
  Component/s: (was: HttpClient (classic))
 Workflow: classic default workflow  (was: Default workflow, 
editable Closed status)
  Key: HTTPCORE-459  (was: HTTPCLIENT-1757)
  Project: HttpComponents HttpCore  (was: HttpComponents HttpClient)

> Make request available to ResponseHandlers
> --
>
> Key: HTTPCORE-459
> URL: https://issues.apache.org/jira/browse/HTTPCORE-459
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Affects Versions: 5.0-alpha3
>Reporter: Tobias Oberlies
> Fix For: 5.0-alpha4
>
>
> We use HttpClients for a system test of a REST API. We are using 
> ResponseHandlers to directly convert the response entity to a data structure 
> that is suitable for assertions.
> This works very well, except for the occasional case where the system under 
> test responds with an unexpected status code. In this case, the response 
> handler throws an exception. For a good error message, it would be useful to 
> also include the request URL. However the request object is not available in 
> the ResponseHandler.handleResponse method.
> So this is a request to also make the HttpRequest object available in the 
> ResponseHandler.handleResponse method. This could be done by adding a getter 
> in the HttpResponse class, or by creating a new interface (e.g. 
> HttpResponseHandler2) with a two-parameter handleResponse method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1404) Provide connection pool usage statistics for PoolingClientConnectionManager

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1404.
---
Resolution: Won't Fix

> Provide connection pool usage statistics for PoolingClientConnectionManager
> ---
>
> Key: HTTPCLIENT-1404
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1404
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (classic)
>Reporter: Allen Wang
>Priority: Minor
> Fix For: Future
>
>
> For clients that have high request rate to their corresponding services, it 
> is critical that the client has an efficient connection pool and reuse free 
> connections as often as possible, and is free from bugs like not releasing 
> resources from http response that causes low reuse of connections and timed 
> out waiting for connection. To meet that requirement, the developers need to 
> have insight of current state of the connection pool.
> Connection pool, like any object pool or cache, needs to have statistics for 
> fine tuning, like Guava CacheBuilder that provides statics for cache hit 
> ratio and many others.
> It will be very beneficial if the PoolingClientConnectionManager provides 
> following statistics:
> - count of occurrences that a free entry is obtained when requesting a 
> connection 
> - count of occurrences that a new entry is created
> - count of occurrences that an entry is released
> - count of occurrences that an entry is deleted
> I was able to provide such statistics for the deprecated 
> ThreadSafeClientConnManager in Ribbon:
> https://github.com/Netflix/ribbon/pull/47
> But it seems that PoolingClientConnectionManager does not provide such hooks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1404) Provide connection pool usage statistics for PoolingClientConnectionManager

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1404:
--
Fix Version/s: (was: Future)

> Provide connection pool usage statistics for PoolingClientConnectionManager
> ---
>
> Key: HTTPCLIENT-1404
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1404
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (classic)
>Reporter: Allen Wang
>Priority: Minor
>
> For clients that have high request rate to their corresponding services, it 
> is critical that the client has an efficient connection pool and reuse free 
> connections as often as possible, and is free from bugs like not releasing 
> resources from http response that causes low reuse of connections and timed 
> out waiting for connection. To meet that requirement, the developers need to 
> have insight of current state of the connection pool.
> Connection pool, like any object pool or cache, needs to have statistics for 
> fine tuning, like Guava CacheBuilder that provides statics for cache hit 
> ratio and many others.
> It will be very beneficial if the PoolingClientConnectionManager provides 
> following statistics:
> - count of occurrences that a free entry is obtained when requesting a 
> connection 
> - count of occurrences that a new entry is created
> - count of occurrences that an entry is released
> - count of occurrences that an entry is deleted
> I was able to provide such statistics for the deprecated 
> ThreadSafeClientConnManager in Ribbon:
> https://github.com/Netflix/ribbon/pull/47
> But it seems that PoolingClientConnectionManager does not provide such hooks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1820) Add support for retrying requests

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1820.
---
   Resolution: Fixed
Fix Version/s: (was: 5.0)
   5.0 Alpha2

Implemented in SVN trunk.

Oleg

> Add support for retrying requests
> -
>
> Key: HTTPCLIENT-1820
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1820
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>Reporter: Joan
>Priority: Minor
> Fix For: 5.0 Alpha2
>
>
> Currently in our application we are retrying requests manually in the 
> 'failed' method within our HttpAsyncResponseConsumer. This generates some 
> collateral problems (that have been solved) but it would be great to have a 
> retry handler in the PoolingNHttpClientConnectionManager to avoid coding 
> retries in callbacks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1620) Httpclient-Win: WindowsNegotiateScheme uses the target credentials on Proxy

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1620.
---
   Resolution: Fixed
Fix Version/s: (was: 5.0)
   5.0 Alpha2
   4.5.4

Should have been fixed by HTTPCLIENT-1833.

Oleg

> Httpclient-Win: WindowsNegotiateScheme uses the target credentials on Proxy
> ---
>
> Key: HTTPCLIENT-1620
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1620
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
> Environment: httpclient-win (4.3 and trunk) Java 8, Windows 8.1
> HTTP Proxy using Windows-Auth: (SPNEGO)
>Reporter: Roman Stoffel
> Fix For: 4.5.4, 5.0 Alpha2
>
>
> Using the WindowsNegotiateScheme + a Windows HTTP proxy which expects windows 
> Auth.
> The WindowsNegotiateScheme notes that authentication is needed, then asks the 
> Windows auth cache. However, it always asks for the target host credentials. 
> Even when the proxy is asking for the credentials.
> Patch: https://github.com/apache/httpclient/pull/28



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1109) Parameterise connection reuse strategy

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1109.
---
   Resolution: Fixed
Fix Version/s: (was: Future)
   5.0 Alpha2

As of 5.0-alpha2 the pooling connection manager supports two connection re-use 
policies: LIFO (ee-use as few connections as possible making it possible for 
connections to become idle and expire), FIFO (re-use all connections equally 
preventing them from becoming idle and expiring)

Oleg



> Parameterise connection reuse strategy
> --
>
> Key: HTTPCLIENT-1109
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1109
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (classic)
>Affects Versions: 4.1.1
>Reporter: James Abley
> Fix For: 5.0 Alpha2
>
>
> c.f. HTTPCLIENT-1108
> A suggestion was made for a different connection re-use approach - one based 
> on https://bugzilla.mozilla.org/show_bug.cgi?id=624739
> I was asked to raise a new issue to cover the possibility of having different 
> connection re-use implementations available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1569) GGSSchemeBase incorrectly spelled

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1569.
---
Resolution: Won't Fix

> GGSSchemeBase incorrectly spelled
> -
>
> Key: HTTPCLIENT-1569
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1569
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 5.0
>
>
> The scheme classname is supposed to be called {{GSSSchemeBase}} or rather 
> {{GssSchemeBase}}. The current name seems to be a unnoticed typo.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1582) SSPI-based auth might fail if output token size is too small

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1582:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: 5.0)
   Stuck

> SSPI-based auth might fail if output token size is too small
> 
>
> Key: HTTPCLIENT-1582
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1582
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>Reporter: Michael Osipov
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> It might happen that a user has many groups, this makes the output token 
> bigger. It might exceed the limit defined by JNA. Refer to JNA's issue 
> [261|https://github.com/twall/jna/issues/261].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1570) GGSSchemeBase blindly assumes that SPNEGO is always used

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1570:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: 5.0)
   Stuck

> GGSSchemeBase blindly assumes that SPNEGO is always used
> 
>
> Key: HTTPCLIENT-1570
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1570
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> Lines 248 to 249 say:
> {code}
> buffer.append(": Negotiate ");
> buffer.append(tokenstr);
> {code}
> This is incorrect. Since this is an abstract class the actual scheme must be 
> passed by the extending class through the super constructor. Same applies for 
> the {{getSchemeName}} method. Correct behavior is implemented in the 
> {{httpclient-win}} module and can be used as a template.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1561) InitializeSecurityContext in WinHttpClient ignores return codes

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1561:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: 5.0)
   Stuck

> InitializeSecurityContext in WinHttpClient ignores return codes
> ---
>
> Key: HTTPCLIENT-1561
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1561
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> In {{WinHttpClient}} {{InitializeSecurityContext}} might not only return 
> {{SEC_I_CONTINUE_NEEDED}} and {{SEC_E_OK}} but also 
> {{SEC_I_COMPLETE_AND_CONTINUE}} and {{SEC_I_COMPLETE_NEEDED}}. The switch 
> case needs to be extended. See 
> [reference|http://msdn.microsoft.com/en-us/library/windows/desktop/aa375509%28v=vs.85%29.aspx].
> As far as I can see, necessary functions aren't even mapped in JNA, so one 
> would need to spawn a ticket with JNA first.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1165) Cache allows multipe requests to retrieve the same cacheable resource from the server in multithreaded environment due to lack of proper locking

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1165:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: Future)
   Stuck

> Cache allows multipe requests to retrieve the same cacheable resource from 
> the server in multithreaded environment due to lack of proper locking
> 
>
> Key: HTTPCLIENT-1165
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1165
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: Snapshot
>Reporter: Manish Tripathi
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> Consider the following scenario:
> Two separate threads are launched at the same time with identical Http 
> requests through CachingHttpClient.
> Both threads look up the same URI in the cache at [almost] the same time and 
> find no cached response for that URI.
> Both threads fall back to backend HttpClient and make identical requests to 
> the server.
> Both threads retrieve the resource and attempt to store it in the cache. 
> The same resource gets retrieved from the server twice and is stored in the 
> cache twice.
> Obviously, the described algorithm is inefficient
> Suggested fix: introduce read-write locking mechanism which would block 
> multiple requests to retrieve the same URI until one of the concurrent 
> requests has either received a response header indicating that the response 
> is not cacheable, or until cacheable response has been fully retrieved and 
> stored in the cache. The proposed pseudo-code follows:
> cachingClient.execute(url) {
>   if (lock_count(url)>0)
> lock=lockingFactory.acquireReadLock(url);
>   else
> lock=lockingFactory.acquireWriteLock(url);
>   response=satisfyFromCache(url);
>   if (response==null) {
> if (lock.isReadLock()) { lock.release(); 
> lock=lockingFactory.acquireWriteLock(url); }
> response=satisfyFromServerAndStoreInCache(url);
>   }
>   lock.release();
>   return response;
> }
> where lockingFactory instance is shared by multiple instances of 
> CachingHttpClient.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1101) adaptive connection pool sizing

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1101.
---
   Resolution: Fixed
Fix Version/s: (was: Future)
   4.5.4

I guess we have to call it as good as it gets.

Oleg

> adaptive connection pool sizing
> ---
>
> Key: HTTPCLIENT-1101
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1101
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (classic)
>Reporter: Jon Moore
>Assignee: Jon Moore
> Fix For: 4.5.4
>
>
> I'm currently working on a patch (wrote most of it on a cross-country flight) 
> that will adapt the size of a per-route connection pool based on the 
> interactions we see from that particular host. There's a sample 
> implementation that does TCP-style additive increase/multiplicative decrease 
> (AIMD) adaptation of the per-route pool where successful requests allow 
> probing for more connections, but socket timeouts, connection timeouts, and 
> 503s all result in backoffs.
> I'm hoping to hook this up for a demo to show multiple clients hitting a 
> server with a fixed capacity where we can kill one client and the others then 
> increase their pool sizes to take advantage of the unused server capacity. We 
> can then restart the client and see things rebalance again. This would enable 
> folks to use HttpClient e.g. in an application server cluster setting, where 
> we wouldn't have to precompute or adjust the connection pool sizes as we 
> add/remove nodes from the cluster (whether intentionally or via failures).
> Once I get that proof of concept working I'll post a patch for review. 
> Roughly the patch hooks into AbstractHttpClient to look either for an 
> HttpResponse or to catch an Exception, then hands those events off to another 
> object to decide whether to backoff or not. In turn, we dynamically manage a 
> ConnPerRouteBean to adjust the maxPerRoute to allow for the pool to grow or 
> shrink naturally with TSSCM. Default implementations are all backwards 
> compatible and don't change behavior.
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Issue Comment Deleted] (HTTPCLIENT-1818) Add support for interceptors to the internal Async IO Threas

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1818:
--
Comment: was deleted

(was: Please do feel to contribute a patch for this feature.

It may not end up in the 4.1 branch but will likely to make it to 5.0

Oleg)

> Add support for interceptors to the internal Async IO Threas
> 
>
> Key: HTTPCLIENT-1818
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1818
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>Reporter: yair ogen
> Fix For: 5.0
>
>
> I have a requirement to attach all logs with a transaction id. I set this ID 
> in Log4j MDC, but I need a way to intercept the request in a way I can set 
> this MDC key in the internal thread pools used by the async client.
> The current interceptors are run before the IO thread pool starts to run,



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (HTTPCLIENT-1626) Rewrite documentation for GSS-API-based authentication

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1626.
---
Resolution: Unresolved

> Rewrite documentation for GSS-API-based authentication
> --
>
> Key: HTTPCLIENT-1626
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1626
> Project: HttpComponents HttpClient
>  Issue Type: Sub-task
>  Components: Documentation
>Affects Versions: 4.5
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1384) Expose CacheInvalidator in CachingHttpClientBuilder

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1384:
--
Fix Version/s: (was: 5.0)
   5.0 Alpha2

> Expose CacheInvalidator in CachingHttpClientBuilder
> ---
>
> Key: HTTPCLIENT-1384
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1384
> Project: HttpComponents HttpClient
>  Issue Type: Wish
>  Components: HttpCache
>Affects Versions: 4.3 Final
>Reporter: Nicolas Richeton
> Fix For: 5.0 Alpha2
>
> Attachments: httpclient-patch.txt, patch.txt
>
>
> There is currently no way to customize the CacheInvalidator. Could it be 
> possible to allow setting a  CacheInvalidator in CachingHttpClientBuilder 
> (eg. CachingHttpClientBuilder#setCacheInvalidator())
> Our use case : 
> - HttpClientCache is used in a Caching Reverse Proxy (shared cache, exposed 
> to public connections)
> - We have to ensure the cache cannot be flush by a random user.  
> - The default CacheInvalidator flushes all variants of an URI when receiving 
> anything other than GET, HEAD (compliant with RFC)
> - It is currently possible for a user to flush the whole cache by sending 
> POST requests of all uri (this may be harmful even only on a home page). 
> While it is not RFC-compliant, we need at least the ability to prevent 
> invalidation in CacheInvalidator#flushInvalidatedCacheEntriesFor and/or 
> control invalidation with custom method  (PURGE) and other criteria (like 
> remote ip)
> The same applies to HttpClientCache 4.2.5: CachingHttpClient which does not 
> allow provide a custom CacheInvalidator
> Would this sound ok for you ? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1630) 304 response causes multiple copies of file in cache

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1630:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: 5.0)
   Stuck

> 304 response causes multiple copies of file in cache
> 
>
> Key: HTTPCLIENT-1630
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1630
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 4.4 Final
>Reporter: Philip Boutros
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
> Attachments: cachedir.png, code.txt, http-sometimes.txt, http.txt
>
>
> See the attached log of a GET with a 200 response followed by a GET to the 
> same URL which receives a 304 response and a CacheResponseStatus of 
> VALIDATED. Using a HttpClient initialized as in the other attachment, these 
> two requests result in 2 identical files in the cache directory, not one. 
> Additional info: This happens with multiple repeated requests that receive 
> 304. Sometime however the file is served from the cache with no additional 
> copy. See new http-sometimes.txt attachment for what that looks like.
> More info: Code work fine against various URLs that include Cache-Control, 
> etc. in their response, but has the same multiple copy behavior against any 
> response that includes only ETag and Last-Modified. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1690) ZipException occurs when content-encoding-header is set for 304-response

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1690:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: Future)
   Stuck

> ZipException occurs when content-encoding-header is set for 304-response 
> -
>
> Key: HTTPCLIENT-1690
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1690
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 4.5
>Reporter: Johannes Gruber
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> h4.Test scenario
> - Setup http server
> - Execute Request twice
> - First response
> -- Status: 200
> -- Cache-Control: public
> -- ETag: 123
> -- Body: some text
> - Second response
> -- Status: 304
> -- Content-Encoding: gzip
> - Effect: java.util.zip.ZipException: Not in GZIP format
> - Expected: Cached response
> h4.JUnit-Test
> - Dependencies: junit 4.11, commons-io 2.4, com.github.tomakehurst:wiremock 
> 1.57
> {code}
> import com.github.tomakehurst.wiremock.junit.WireMockRule;
> import org.apache.commons.io.IOUtils;
> import org.apache.http.client.methods.CloseableHttpResponse;
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClientBuilder;
> import org.apache.http.impl.client.cache.CacheConfig;
> import org.apache.http.impl.client.cache.CachingHttpClientBuilder;
> import org.junit.Assert;
> import org.junit.Rule;
> import org.junit.Test;
> import java.io.IOException;
> import static com.github.tomakehurst.wiremock.client.WireMock.aResponse;
> import static com.github.tomakehurst.wiremock.client.WireMock.equalTo;
> import static com.github.tomakehurst.wiremock.client.WireMock.get;
> import static com.github.tomakehurst.wiremock.client.WireMock.stubFor;
> import static com.github.tomakehurst.wiremock.client.WireMock.urlEqualTo;
> public class GZipCachingHttpClientBuilderTest  {
>   private static final String TEST_BODY = "Sometext";
>   @Rule
>   public WireMockRule wireMockRule = new WireMockRule(0);
>   @Test
>   public void testGzipError() throws Exception {
> stubFor(get(urlEqualTo("/my/resource"))
> .willReturn(aResponse()
> .withStatus(200)
> .withHeader("Cache-Control", "public")
> .withHeader("ETag", "123")
> .withBody(TEST_BODY)
> ));
> stubFor(get(urlEqualTo("/my/resource"))
> .withHeader("If-None-Match", equalTo("123"))
> .willReturn(aResponse()
> .withHeader("Content-Encoding", "gzip")
> .withStatus(304)
> ));
> CacheConfig.Builder cfgBuilder = CacheConfig.custom();
> CacheConfig cfg = cfgBuilder.setMaxCacheEntries(1024).build();
> HttpClientBuilder bld = 
> CachingHttpClientBuilder.create().setCacheConfig(cfg);
> CloseableHttpClient client = bld.build();
> executeRequest(client);
> executeRequest(client); // second request causes Exception :-(
>   }
>   private void executeRequest(CloseableHttpClient client) throws IOException {
> int port = wireMockRule.port();
> CloseableHttpResponse resp = client.execute(new 
> HttpGet("http://localhost:"+port+"/my/resource;));
> Assert.assertEquals(TEST_BODY, 
> IOUtils.toString(resp.getEntity().getContent()));
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1347) gzip responses doubly cached

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1347:
--
   Labels: stuck volunteers-wanted  (was: )
Fix Version/s: (was: 5.0)
   Stuck

> gzip responses doubly cached
> 
>
> Key: HTTPCLIENT-1347
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1347
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.2.5
> Environment: ARCH Linux kernel 3.8.8-1
> node.js 0.8.22
>Reporter: Adam Patacchiola
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
> Attachments: httpClientCacheTest.tar.gz, httpClientTestServer.js, 
> Screen Shot 2014-01-11 at 7.11.36 PM.png, Screen Shot 2014-01-13 at 3.56.19 
> PM.png, Showing_entry_pointer.png
>
>
> Compressed responses are cached twice. 
> Run the attached server (node.js 0.8.22) and client tests. Create an "assets" 
> directory under where you are running the server and add two files named 1 
> and 2 ( < 100 bytes) . You will see that after the test is run the cache 
> dump output displays 2 sets of entries for each request, each containing the 
> full content length of the file.
> Changing the implementation of HttpCacheStorage updateEntry to not update non 
> existent entries (as I believe the correct implementation should do) throws 
> exceptions. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCLIENT-1598) Native Windows Negotiate/NTLM via JNA + 407 Proxy Authentication Required

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1598:
--
   Labels: stuck volunteers-wanted  (was: 407 jna native ntlm)
Fix Version/s: (was: 5.0)
   Stuck

> Native Windows Negotiate/NTLM via JNA + 407 Proxy Authentication Required
> -
>
> Key: HTTPCLIENT-1598
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1598
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
> Environment: Windows 8
>Reporter: Giacomo Boccardo
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
> Attachments: curl7.40Output.txt, curlOutput.txt, log.txt, sample.java
>
>
> I'm trying to use the native Windows NTLM negotiation as described at 
> http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient-win/src/examples/org/apache/http/examples/client/win/ClientWinAuth.java
> but I need to explicitly set a proxy.
> {code:java}
> if (!WinHttpClients.isWinAuthAvailable()) {
>   System.out.println("Integrated Win auth is not supported!!!");
> }
> HttpClientBuilder httpClientBuilder = WinHttpClients.custom();
> HttpHost httpProxy = new HttpHost("proxyserver.example.com", 3128);
> httpClientBuilder.setProxy(httpProxy);
> CloseableHttpClient httpclient = httpClientBuilder.build();
> try {
>   HttpGet httpget = new HttpGet("http://www.google.it;);
>   System.out.println("Executing request " + httpget.getRequestLine());
>   CloseableHttpResponse response = httpclient.execute(httpget);
>   try {
>   System.out.println("");
>   System.out.println(response.getStatusLine());
>   EntityUtils.consume(response.getEntity());
>   } finally {
>   response.close();
>   }
> } finally {
>   httpclient.close();
> }
> {code}
> The response contains the following line
> {{HTTP/1.0 407 Proxy Authentication Required}}
> In the attachments both the source code above and the complete log of the 
> negotiation (I obviously changed the real proxy).
> What's wrong?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (HTTPCORE-454) Add a Timeout class that extends TimeValue

[Oleg Kalnichevski (JIRA)]

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

Oleg Kalnichevski updated HTTPCORE-454:
---
Fix Version/s: (was: 5.0-alpha3)
   5.0

> 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.3.15#6346)

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

[ANNOUNCEMENT] HttpComponents Core 5.0 alpha3 released

[Oleg Kalnichevski]

The Apache HttpComponents project is pleased to announce 5.0-alpha3
release of HttpComponents Core. 

This is a major release that renders HttpCore API incompatible with the
stable 4.x branch and upgrades HTTP/1.1 and HTTP/2 protocol conformance
to the requirements and recommendations of the latest protocol
specification.

Notable changes and features included in the 5.0 series are:

* Partial support for HTTP/2 protocol and conformance to requirements
and recommendations of the latest HTTP/2 protocol specification (RFC
7540, RFC 7541)

  Supported features:

** HPACK header compression
** stream multiplexing (client and server)
** flow control
** response push (client and server)
** message trailers
** expect-continue handshake
** connection validation (ping)
** application-layer protocol negotiation (ALPN) on Java 1.9+
** TLS 1.2 security features

   Unsupported features:

** padding of outgoing frames
** stream priority
** plain connection HTTP/1.1 upgrade
** CONNECT method

* Improved conformance to requirements and recommendations of the
latest HTTP/1.1 protocol specification (RFC 7230, RFC 7231)

* New asynchronous HTTP transport APIs consistent for both HTTP/1.1 and
HTTP/2 transport.

* Improved HTTP/1.1 and HTTP/2 requester and server implementations.

* Redesigned connection pool implementation with reduced pool lock
contention.

* Plug-in mechanism for HTTP/1.1 protocol switch / upgrade.

* Package name space changed to 'org.apache.hc.core5'

* Maven group id changed to 'org.apache.httpcomponents.core5'

HttpCore 5.0 releases can be co-located with earlier versions.

Please note that as of 5.0 HttpCore requires Java 1.7 or newer.

!!!IMPORTANT!!! 
We have been considering upgrading minimal JRE level to 1.8 for all
HttpCore 5.x artifacts. If you would like HttpCore to remain 1.7
compatible please do let us know by posting a message to dev@hc.apache.
org  

Please note that at this point 5.0 APIs are considered API experimental
and unstable and are expected to change in the coming releases without
providing a migration path.

Download - 
Release notes - 
HttpComponents site - 

About HttpComponents Core

HttpCore is a set of HTTP/1.1 and HTTP/2 transport components that can
be used to build custom client and server side HTTP services with a
minimal footprint.

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

[jira] [Closed] (HTTPCORE-455) The client does not check if the IO thread is alive

[Allen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Allen closed HTTPCORE-455.
--

> The client does not check if the IO thread is alive
> ---
>
> Key: HTTPCORE-455
> URL: https://issues.apache.org/jira/browse/HTTPCORE-455
> Project: HttpComponents HttpCore
>  Issue Type: Bug
> Environment: Mac OSX, Java 8
>Reporter: Allen
> Fix For: 4.4.7, 5.0-alpha3
>
>
> When I developed with the latest HttpAsyncclient, it was hard for me to know 
> whether the IO thread in BaseIOReactor was alive。 For example, if I throw an 
> error in the callback，the IO thread will terminate,but the connecting thread  
> will not check if the IO thread is alive,and will still add new  channels to 
> the dispatcher。
> The java code:
>  CloseableHttpAsyncClient client = HttpAsyncClients.custom().build();
> client.start();
> HttpUriRequest getRequest = new HttpGet("www.google.com");
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
> throw new StackOverflowError();
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> for(int i = 0 ; i < 100 ; i++){
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
> 
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> }
> one of the IO threads is dead，but the java Error dose not be caught，and hte 
> client will continue work and add new channels to the dispather, but the 
> newChannel queue will be not be consumed, so I want to know is there any 
> method to deal with this situation.
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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