Re: [VOTE] Release HttpClient 5.0.1 based on RC1
[x] +1 Release the packages as HttpClient 5.0.1 On Wed, Jun 10, 2020 at 4:26 PM Oleg Kalnichevski wrote: > [x] +1 Release the packages as HttpClient 5.0.1 > > On Mon, 2020-06-08 at 19:59 +0200, Oleg Kalnichevski wrote: > > Please vote on releasing these packages as HttpClient 5.0.1. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.0.1-RC1/RELEASE_NOTES-5.0.x.txt > > > > Maven artefacts: > > > > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1115/org/apache/httpcomponents/client5/ > > > > Git Tag: 5.0.1-RC1 > > https://github.com/apache/httpcomponents-client/tree/5.0.1-RC1 > > > > Packages: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.0.1-RC1 > > revision 39986 > > > > Hashes: > > eb9e00ffef66ae16d3420b0200b0bafbf76b283ae6597e6496da8b66ebab37cad34b > > 9b0038c6243b201de3735912ad1d2d23722bf9854058aab9fd1dc394f4b9 > > httpcomponents-client-5.0.1-src.tar.gz > > 8a20b28ef4bfb3eb4b08d5c07e522aa6e9e87686f300de6082ba741cee1a7d4570c9 > > 1405122b4637d2d14297b20f30582f69925a0c0c14009afec96bbebdc6cd > > httpcomponents-client-5.0.1-bin.tar.gz > > 2f5e8143f230d50776ca629e3ee76cb04fdc719a71a49bbd2b8a52cb91ff9286ca0b > > 991e1538c4c388a3d772cd396aaa62bfd9a114e06beabb41f28c748f6eb2 > > httpcomponents-client-5.0.1-src.zip > > fb3fef64a4b4517e39cc058ab377c056fb1fb33fda42cadc2de35047781f0f2f42dc > > acaff2031faba1f25e7c8215c924518f40b76bfb0939f786e4cb95ba8ebf > > httpcomponents-client-5.0.1-bin.zip > > > > Keys: > > http://www.apache.org/dist/httpcomponents/httpclient/KEYS > > > > --- > > --- > > Vote: HttpClient 5.0.1 release > > [ ] +1 Release the packages as HttpClient 5.0.1. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
[jira] [Commented] (HTTPCLIENT-2058) DefaultHostnameVerifier does not verify local DNS names
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053106#comment-17053106 ] Philippe Mouawad commented on HTTPCLIENT-2058: -- This looks like a duplicate of HTTPCLIENT-2047 which is fixed in currently under release 4.5.12 RC1 Can you check if this is solved using this and give your feedback ? [https://repository.apache.org/content/repositories/orgapachehttpcomponents-1113/org/apache/httpcomponents/] Thanks > DefaultHostnameVerifier does not verify local DNS names > --- > > Key: HTTPCLIENT-2058 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2058 > Project: HttpComponents HttpClient > Issue Type: Bug >Affects Versions: 4.5.11 >Reporter: Farzad Kohantorabi >Priority: Major > Attachments: httpcomponentsbug.zip > > > This seems to be a problem that's introduced in 4.5.11. > DefaultHostnameVerifier does not verify local DNS names anymore and throws > the following error for one of our certs. The same code works fine in 4.5.10. > {code:java} > Certificate for doesn't match any of the subject > alternative names: [app-uat.le.dp.xyz.local, C1234.LE.DP.XYZ.LOCAL] executing > POST https://app-uat.le.dp.xyz.local:8443/someurl {code} > I traced the issue down to > org.apache.http.conn.ssl.DefaultHostnameVerifier#matchIdentity line 204 where > publicSuffixMatcher.getDomainRoot(identity, domainType) returns null for > app-uat.le.dp.xyz.local where as in version 4.5.10 it returns "local". > Attached maven project has a unit test that uses a self signed cert to > exhibit the problem. I've included both the cert and the file that I used to > create the cert. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: [VOTE] Release HttpClient 4.5.12 based on RC1
[X] +1 Release the packages as HttpClient 4.5.12. Thanks for it On Fri, Mar 6, 2020 at 5:43 AM Asankha C. Perera wrote: > > > Vote: HttpClient 4.5.12 release > > [X] +1 Release the packages as HttpClient 4.5.12. > > [ ] -1 I am against releasing the packages (must include a reason). > > -- > Asankha C. Perera > > SLAppForge https://slappforge.com > AdroitLogic, https://www.adroitlogic.com > > https://serverless.asankha.com/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpClient 5.0 based on RC1
+1 Congrats ! On Wed, Feb 19, 2020 at 9:21 PM Michael Osipov wrote: > Am 2020-02-19 um 10:41 schrieb Oleg Kalnichevski: > > Please vote on releasing these packages as HttpClient 5.0. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.0-RC1/RELEASE_NOTES-5.0.x.txt > > > > Maven artefacts: > > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1112/org/apache/httpcomponents/client5/ > > > > Git Tag: 5.0-RC1 > > https://github.com/apache/httpcomponents-client/tree/5.0-RC1 > > > > Packages: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.0-RC1 > > revision 38158 > > > > Hashes: > > > > 2d078937f895f72612b0bf77253d2090080e797a8f40e65e1a1e3eb24db2d2f405b1fecf3a8bc2e5a9ca7d7bb7136a73ae8eeea94a9123d3f8246a98fc0537ea > httpcomponents-client-5.0-src.zip > > > > 6731d6d0219f52e97b191c9facc87d5fcffb1368438f5f1a1a1413485e5605050ff85fa27a208a6fe0b3f7439e597992baad2719bd258236317578bb32d0d5d7 > httpcomponents-client-5.0-bin.tar.gz > > > > a04a920ad90ead3e4c2f0855e28b29fe4e9495ed311e359585e2ec475852b3f86f75f155885b1e95072a4d7e76a40553d97494f38b8e187649f8957f8a823f78 > httpcomponents-client-5.0-src.tar.gz > > > > b310c730cff40adf13db2a9a89ff552992421b7193d79515b6dac1d88d348ad42137238a8c188cdf56388723fba4a3eae26ba486d5d68b3d6ec6f0e1b367760e > httpcomponents-client-5.0-bin.zip > > > > Keys: > > http://www.apache.org/dist/httpcomponents/httpclient/KEYS > > > > > -- > > Vote: HttpClient 5.0 release > > [ ] +1 Release the packages as HttpClient 5.0. > > [ ] -1 I am against releasing the packages (must include a reason). > > +1 > > Looking forward too. > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpClient 4.5.9 based on RC1
+1 On Mon, Jun 10, 2019 at 6:01 PM Gary Gregory wrote: > +1 > > Apache RAT check OK. > Apache CLIRR check OK. > > Ran ' mvn clean site -V -P!use-toolchains' OK with: > > Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; > 2019-04-04T15:00:29-04:00) > Maven home: C:\Java\apache-maven-3.6.1\bin\.. > Java version: 11.0.3, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk-11.0.3 > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > C:\temp\rc\httpcomponents-client>mvn -version > Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; > 2019-04-04T15:00:29-04:00) > Maven home: C:\Java\apache-maven-3.6.1\bin\.. > Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_212\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Ran ' mvn clean package -V -P!use-toolchains' OK with: > > Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; > 2019-04-04T15:00:29-04:00) > Maven home: C:\Java\apache-maven-3.6.1\bin\.. > Java version: 12.0.1, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\openjdk\jdk-12.0.1 > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Which failed due to our Java 6 requirement: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile > (default-compile) on project httpclient: Compilation failure: Compilation > failure: > [ERROR] Source option 6 is no longer supported. Use 7 or later. > [ERROR] Target option 6 is no longer supported. Use 7 or later. > > Gary > > On Fri, Jun 7, 2019 at 9:33 AM Oleg Kalnichevski wrote: > > > Please vote on releasing these packages as HttpClient 4.5.9. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.9-RC1/RELEASE_NOTES-4.5.x.txt > > > > Maven artefacts: > > > > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1098/org/apache/httpcomponents/ > > > > Git Tag: 4.5.9-RC1 > > https://github.com/apache/httpcomponents-client/tree/4.5.9-RC1 > > > > Packages: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.9-RC1 > > revision 34450 > > > > Hashes: > > > ee2cbbbc95f6d97fedbb6214bac079ce3d571b744268ff17245cb9d4a2a8bd6cea2e32a464263a912d17eb6fdc70eff18d4e9c77671d695292558c936d96bf2f > > httpcomponents-client-4.5.9-bin.tar.gz > > > 6b0812cc72f91477c4bde32a70151f4d404a2c31f19170f6a39b553cce90e2ed921e642fab2ef1f2f40c3f15220df921f9d40222fffe1c9b511881d7153a5a0e > > httpcomponents-client-4.5.9-bin.zip > > > bd8f1b9d4a442f7057f2a73eb68d0e0cad5f32bed7f0444fe1ac4d016729c6c1e04fa9d74bdd36bf617b0819ebcc10bd4bb12de9c85eb4513bce63d6b021db06 > > httpcomponents-client-4.5.9-src.zip > > > 587d5d4cd5a21e3d8b5e6214fe8b8288efeecd5fc5a055ac53d5f9f62c276dfb76e4a333952d34e5eccab73139f2b7d9b2b1805e6d07c2e4807152c962423d17 > > httpcomponents-client-4.5.9-src.tar.gz > > > > Keys: > > http://www.apache.org/dist/httpcomponents/httpclient/KEYS > > > > > -- > > Vote: HttpClient 4.5.9 release > > [ ] +1 Release the packages as HttpClient 4.5.9. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpClient 4.5.8 based on RC1
+1 (non pmc :) ) On Friday, March 29, 2019, Gary Gregory wrote: > Ping for another vote from the PMC... > > Gary > > On Tue, Mar 26, 2019 at 10:38 AM Oleg Kalnichevski > wrote: > > > Please vote on releasing these packages as HttpClient 4.5.8. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/ > httpclient-4.5.8-RC1/RELEASE_NOTES-4.5.x.txt > > > > Maven artefacts: > > > > https://repository.apache.org/content/repositories/ > orgapachehttpcomponents-1094/org/apache/httpcomponents/ > > > > Git Tag: 4.5.8-RC1 > > https://github.com/apache/httpcomponents-client/tree/4.5.8-RC1 > > > > Packages: > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/ > httpclient-4.5.8-RC1 > > revision 33201 > > > > Hashes: > > acf43f783e18d2e9bbcadc09a6e54fb962508e3682281768307c553d2547 > 906c9f93988f67c6ba9f3e4443952514593875541244fae486c10f41c17d11630336 > > httpcomponents-client-4.5.8-bin.tar.gz > > e990705105e93067be115b2ec9d92650c30e4228a2e35e9a2fe8041b4b8c > 62fa7696972bb3691de331d16d8a1adb0e93dabbf15bcc0088c296669b2a8b27d0bd > > httpcomponents-client-4.5.8-src.zip > > 0730de98696dd97b669a157a1fdfb74a56d21d9dc04266ffe80e06a02cf5 > 463ac85130262dc91fcc27ac6672ba38c51f6f5379e4667959254377d2cb8b6ddd19 > > httpcomponents-client-4.5.8-src.tar.gz > > e4653ba14dd7906afdf572c417e836edd1a4edc3217e3218c1fab300df82 > 74de1cd1b8ff89f2342274f2e12db507734736356d320adc887a2ee79e91f424f785 > > httpcomponents-client-4.5.8-bin.zip > > > > Keys: > > http://www.apache.org/dist/httpcomponents/httpclient/KEYS > > > > > -- > > Vote: HttpClient 4.5.8 release > > [ ] +1 Release the packages as HttpClient 4.5.8. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > >
Re: HttpClient 5.0 migration guide
Great initiative ! Thanks a lot Oleg. Will certainly use it soon with JMeter and try to give feedback. On Sat, Feb 23, 2019 at 12:35 AM Gary Gregory wrote: > The docs look really nice. I just started looking and I hope to be able to > read through the whole site over the next week. > > CloseableHttpClient instances should be closed when no longer needed or > about to go out of score. > > We should also say that this can be used in a try-with-resources statement. > > Gary > > On Wed, Feb 20, 2019 at 2:31 PM Oleg Kalnichevski > wrote: > > > Folks > > > > I finally got around to completing the first revision of the HttpClient > > 5.0 migration guide. > > > > https://ok2c.github.io/httpclient-migration-guide/ > > > > I would really appreciate if a native English speaker could proof-read > > it and possibly improve the style, not just grammar. > > > > https://github.com/ok2c/httpclient-migration-guide > > > > I also would like to add a reference to this guide from our project at > > some point of time. > > > > Cheers > > > > Oleg > > > > > > > > --------- > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > -- Cordialement. Philippe Mouawad.
Re: [ANNOUNCEMENT] HttpComponents Client 4.5.7 GA Released
Thanks for this release. It appears 4.5.7 artifact was not published on Maven. Regards On Thu, Jan 24, 2019 at 10:34 PM Oleg Kalnichevski wrote: > The Apache HttpComponents project is pleased to announce 4.5.7 GA > release of HttpComponents HttpClient. > > This is a maintenance release that corrects Automatic-Module-Name > definitions added in the previous release and fixes a number of minor > defects discovered since 4.5.6. > > Download - <http://hc.apache.org/downloads.cgi> > Release notes - > <https://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4. > 5.x.txt> > HttpComponents site - <http://hc.apache.org/> > > About HttpComponents HttpClient > > The Hyper-Text Transfer Protocol (HTTP) is perhaps the most significant > protocol used on the Internet today. Web services, network-enabled > appliances and the growth of network computing continue to expand the > role of the HTTP protocol beyond user-driven web browsers, while > increasing the number of applications that require HTTP support. > > Although the java.net package provides basic functionality for > accessing resources via HTTP, it doesn't provide the full flexibility > or functionality needed by many applications. HttpClient seeks to fill > this void by providing an efficient, up-to-date, and feature-rich > package implementing the client side of the most recent HTTP standards > and recommendations. > > Designed for extension while providing robust support for the base HTTP > protocol, HttpClient may be of interest to anyone building HTTP-aware > client applications such as web browsers, web service clients, or > systems that leverage or extend the HTTP protocol for distributed > communication. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpClient 4.5.7 based on RC1
Hello, [x] +1 Release the packages as HttpClient 4.5.7 Tests done with JMeter unit and integration tests. Reported bug is fixed. Thanks for release ! Regards On Sun, Jan 20, 2019 at 5:53 PM Oleg Kalnichevski wrote: > [x] +1 Release the packages as HttpClient 4.5.7 > > > On Sun, 2019-01-20 at 15:34 +0100, Oleg Kalnichevski wrote: > > Please vote on releasing these packages as HttpClient 4.5.7. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.7-RC1/RELEASE_NOTES-4.5.x.txt > > > > Maven artefacts: > > > > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1092/org/apache/httpcomponents/ > > > > Git Tag: 4.5.7-RC1 > > https://github.com/apache/httpcomponents-client/tree/4.5.7-RC1 > > > > Packages: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.7-RC1 > > revision 32055 > > > > Hashes: > > 3dd952009dfd9a64b434b90b385916e4b52548d1a5ba1783b3547030fa346a4f2157 > > 1738a616c59de8616304e9ecb6e3d436c0ab60d6a299767291c11b4ffb8b > > httpcomponents-client-4.5.7-src.zip > > a02717894d519ff88ec988f2cadd2b53832d7bf1ba87f54ccc3922d0ca62ce349e32 > > d297611720aa993d7214564e43ab5471f7405e724499d354052617818680 > > httpcomponents-client-4.5.7-src.tar.gz > > 0e897889d79fea27fa1d01bd76abea7a2eb44013ba2a3c77b63ed9e170f3c5101fd6 > > 2e21eb5c2978a7ca975f8922a3214572426af1546d2a86d3a3c7d2c5618b > > httpcomponents-client-4.5.7-bin.zip > > cbd284eb22296edf77d07efad2254864713af3cf06c23b43c4c127e52d2f3c437eb8 > > 3f09c427ba2134b8d323bed6c7e33ffe3556a4f86d1c5c79092b72d07353 > > httpcomponents-client-4.5.7-bin.tar.gz > > > > Keys: > > http://www.apache.org/dist/httpcomponents/httpclient/KEYS > > > > --- > > --- > > Vote: HttpClient 4.5.7 release > > [ ] +1 Release the packages as HttpClient 4.5.7. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpCore 4.4.11 based on RC1
[+1] I support this release Thanks for release On Tue, Jan 15, 2019 at 11:58 AM Oleg Kalnichevski wrote: > Please vote on releasing these packages as HttpCore 4.4.11. > The vote is open for the at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Release notes: > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-4.4.11-RC1/RELEASE_NOTES-4.4.x.txt > > Maven artefacts: > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1091/org/apache/httpcomponents/ > > Git Tag: 4.4.11-RC1 > https://github.com/apache/httpcomponents-core/tree/4.4.11-RC1 > > Packages: > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-4.4.11-RC1 > revision 31967 > > Hashes: > > 41f42692d5edb40b74975998766270a19c0736e6eeba67b19d30b2f4e93c703800636e80dc7a2e531ed5d194546d9429832c4794495180dabb501151a1d26f0e > httpcomponents-core-4.4.11-bin.tar.gz > > a34de278b5bf81f1d077cee2e0c1dbfc2a3bce767d618cdc88b4a0606b80f8487a24bd669337aa2a60badd207c3f07d2695a2c1975922ab48f1eb45147cb307b > httpcomponents-core-4.4.11-src.zip > > bc70f1c12df290b68afe0d29eba07edb5b9cda2fa1c6802fbb0d1e3906104ea6273caafbcdb9123c138db8236efa983b76d6708992d02e2690ad9a3c6e20b5f3 > httpcomponents-core-4.4.11-src.tar.gz > > 9278b3d3c32ae433ed70f80a1029946a6d0497583aa62b3222c358dc2137a407a285d4d86bc2e726624cea727e40ffe5892ae264c8605c968e10dd174fc38746 > httpcomponents-core-4.4.11-bin.zip > > Keys: > http://www.apache.org/dist/httpcomponents/httpcore/KEYS > > -- > Vote: HttpCore 4.4.11 release > [ ] +1 Release the packages as HttpCore 4.4.11. > [ ] -1 I am against releasing the packages (must include a reason). > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
[jira] [Commented] (HTTPCLIENT-1956) Using a Proxy with HttpClient overwrite attributes stored under HttpContext for the main request (not proxy one)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723452#comment-16723452 ] Philippe Mouawad commented on HTTPCLIENT-1956: -- Hello, I was able to test and it seems issue is fixed, thanks ! But I still notice issues when using proxy compared to direct request. Shall I open another bug ? Thanks > Using a Proxy with HttpClient overwrite attributes stored under HttpContext > for the main request (not proxy one) > > > Key: HTTPCLIENT-1956 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1956 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.6 > Reporter: Philippe Mouawad >Priority: Major > Attachments: ProxyBug.java > > > At JMeter, we had this bug report on JMeter 5.0 which uses last GA version of > HTTPCORE- 4.4.10/HTTPCLIENT-4.5.6: > * [https://bz.apache.org/bugzilla/show_bug.cgi?id=62852] > * > The problem is that below method behaves differently if request is emitted > directly or through a Proxy: > * localContext.getAttribute(HttpCoreContext.HTTP_REQUEST); > If you run code below and inspect: > * localContext.getAttribute(HttpCoreContext.HTTP_REQUEST); > While you should get this (and you indeed get this if you don't use a proxy): > * The GET method > * All headers: > * X-Sleep:5 > * Host: [jmeter.apache.org:443|http://jmeter.apache.org:443/], > * User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161) > Instead you get: > * CONNECT method (the proxy related one) > * Partial Headers: > * Host: [jmeter.apache.org:443|http://jmeter.apache.org:443/], > * User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161) > In test case below: > * [http://localhost:|http://localhost:/] act as proxy (you can use > JMeter HTTP Test Script recorder to start a proxy or any proxy implementation > running on that port) > * [https://jmeter.apache.org|https://jmeter.apache.org/] is the target > website, but you can use any site you want > * X-Sleep is the custom header that is lost for example > > Find attached JUnit reproducing issue. > The impact can be wider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1956) Using a Proxy with HttpClient overwrite attributes stored under HttpContext for the main request (not proxy one)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16723426#comment-16723426 ] Philippe Mouawad commented on HTTPCLIENT-1956: -- Hello [~olegk], Thanks for handling this issue rapidly. Is there a particular procedure to build the project ? I cloned repo, checked out branch HTTPCLIENT-1956 and ran mvn clean install with 3.5.2 version, it fails with: Failed to execute goal org.apache.rat:apache-rat-plugin:0.12:check (default) on project httpcomponents-client: Too many files with unapproved license: 1 See RAT report in: /data/jmeter/httpcomponents-client/target/rat.txt -> [Help 1] I commented the plugin, it then fails with this because of SSL issue with JDK7: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on project httpclient: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test failed: Plugin org.apache.maven.plugins:maven-surefire-plugin:2.22.1 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-surefire-plugin:jar:2.22.1 -> org.apache.maven.surefire:maven-surefire-common:jar:2.22.1: Failed to read artifact descriptor for org.apache.maven.surefire:maven-surefire-common:jar:2.22.1: Could not transfer artifact org.apache.maven.surefire:maven-surefire-common:pom:2.22.1 from/to central (https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version -> [Help 1] Then I try to build with 1.8, it fails due to Api check: Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.16:check (checkAPIcompatibility) on project httpclient: Signature errors found. Verify them and ignore them with the proper annotation if needed. -> > Using a Proxy with HttpClient overwrite attributes stored under HttpContext > for the main request (not proxy one) > > > Key: HTTPCLIENT-1956 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1956 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.6 >Reporter: Philippe Mouawad >Priority: Major > Attachments: ProxyBug.java > > > At JMeter, we had this bug report on JMeter 5.0 which uses last GA version of > HTTPCORE- 4.4.10/HTTPCLIENT-4.5.6: > * [https://bz.apache.org/bugzilla/show_bug.cgi?id=62852] > * > The problem is that below method behaves differently if request is emitted > directly or through a Proxy: > * localContext.getAttribute(HttpCoreContext.HTTP_REQUEST); > If you run code below and inspect: > * localContext.getAttribute(HttpCoreContext.HTTP_REQUEST); > While you should get this (and you indeed get this if you don't use a proxy): > * The GET method > * All headers: > * X-Sleep:5 > * Host: [jmeter.apache.org:443|http://jmeter.apache.org:443/], > * User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161) > Instead you get: > * CONNECT method (the proxy related one) > * Partial Headers: > * Host: [jmeter.apache.org:443|http://jmeter.apache.org:443/], > * User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161) > In test case below: > * [http://localhost:|http://localhost:/] act as proxy (you can use > JMeter HTTP Test Script recorder to start a proxy or any proxy implementation > running on that port) > * [https://jmeter.apache.org|https://jmeter.apache.org/] is the target > website, but you can use any site you want > * X-Sleep is the custom header that is lost for example > > Find attached JUnit reproducing issue. > The impact can be wider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1956) Using a Proxy with HttpClient overwrite attributes stored under HttpContext for the main request (not proxy one)
Philippe Mouawad created HTTPCLIENT-1956: Summary: Using a Proxy with HttpClient overwrite attributes stored under HttpContext for the main request (not proxy one) Key: HTTPCLIENT-1956 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1956 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient (classic) Affects Versions: 4.5.6 Reporter: Philippe Mouawad Attachments: ProxyBug.java At JMeter, we had this bug report on JMeter 5.0 which uses last GA version of HTTPCORE- 4.4.10/HTTPCLIENT-4.5.6: * [https://bz.apache.org/bugzilla/show_bug.cgi?id=62852] * The problem is that below method behaves differently if request is emitted directly or through a Proxy: * localContext.getAttribute(HttpCoreContext.HTTP_REQUEST); If you run code below and inspect: * localContext.getAttribute(HttpCoreContext.HTTP_REQUEST); While you should get this (and you indeed get this if you don't use a proxy): * The GET method * All headers: * X-Sleep:5 * Host: [jmeter.apache.org:443|http://jmeter.apache.org:443/], * User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161) Instead you get: * CONNECT method (the proxy related one) * Partial Headers: * Host: [jmeter.apache.org:443|http://jmeter.apache.org:443/], * User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161) In test case below: * [http://localhost:|http://localhost:/] act as proxy (you can use JMeter HTTP Test Script recorder to start a proxy or any proxy implementation running on that port) * [https://jmeter.apache.org|https://jmeter.apache.org/] is the target website, but you can use any site you want * X-Sleep is the custom header that is lost for example Find attached JUnit reproducing issue. The impact can be wider -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: [httpclient] Better user agent header?
Hello, That might not be a good idea regarding security as it reveals information on client machine. Regards On Friday, March 30, 2018, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > Right now, the HttpClient is of the form: > > User-Agent: Apache-HttpClient/4.5.5 (Java/1.8.0_162) > > With the stack I am working with, it would be handy if the header > reflected: > > - The Java vendor > - Operating system name and version. > > For example: > > User-Agent: Apache-HttpClient/4.5.5 (Oracle Corporation/Java/1.8.0_162) > Windows/10.0 (amd64) > > Any thoughts for or against adding this to the user agent string? > > Gary > -- Cordialement. Philippe Mouawad. Ubik-Ingénierie UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
HttpClient 5.0 is now feature complete
Great news Oleg ! Thanks for your hard work. Hope to use it soon in our project. Regards On Mon, Jan 8, 2018 at 11:39 AM, Oleg Kalnichevskiwrote: > Folks, > > HttpClient 5.0 is now feature complete and ready to go BETA. I do not > intent to add any more features or make any big API changes to > HttpClient master anymore, unless there is a very strong reason for > doing so. > > The only thing that blocks HttpClient 5.0 BETA1 is HTTPCLIENT-1664 [1] > > [1] https://issues.apache.org/jira/browse/HTTPCLIENT-1664 > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: [VOTE] Release HttpClient 4.5.4 based on RC1
[x] +1 Release the packages as HttpClient 4.5.4 On Tue, Nov 28, 2017 at 9:13 AM, Oleg Kalnichevski <ol...@apache.org> wrote: > [x] +1 Release the packages as HttpClient 4.5.4 >> > > On Mon, Nov 27, 2017 at 10:54 AM, Oleg Kalnichevski <ol...@apache.org> > wrote: > >> Please vote on releasing these packages as HttpClient 4.5.4. >> The vote is open for the at least 72 hours, and only votes from >> HttpComponents PMC members are binding. The vote passes if at least >> three binding +1 votes are cast and there are more +1 than -1 votes. >> >> Release notes: >> >> https://dist.apache.org/repos/dist/dev/httpcomponents/httpcl >> ient-4.5.4-RC1/RELEASE_NOTES-4.5.x.txt >> >> Maven artefacts: >> >> https://repository.apache.org/content/repositories/orgapache >> httpcomponents-1071/org/apache/httpcomponents/ >> >> Git Tag: 4.5.4-RC1 >> https://github.com/apache/httpcomponents-client/tree/4.5.4-RC1 >> >> Packages: >> >> https://dist.apache.org/repos/dist/dev/httpcomponents/httpcl >> ient-4.5.4-RC1 >> revision 23288 >> >> Hashes: >> 114569d7c8de4de6cd178c610c8bf68f httpcomponents-client-4.5.4-src.tar.gz >> c929bab52e49e11a345993be531784c3 httpcomponents-client-4.5.4-osgi-bin.zip >> 05a8b6bb3eba517f69099882105a9048 httpcomponents-client-4.5.4-os >> gi-bin.tar.gz >> c53fe2258ec25396890f1c68aa40daa6 httpcomponents-client-4.5.4-bin.zip >> 87c15013da44acb9a08aa04711901876 httpcomponents-client-4.5.4-bin.tar.gz >> d6031d0f7f1b628978f5c75f6dc73589 httpcomponents-client-4.5.4-src.zip >> >> Keys: >> http://www.apache.org/dist/httpcomponents/httpclient/KEYS >> >> >> -- >> Vote: HttpClient 4.5.4 release >> [ ] +1 Release the packages as HttpClient 4.5.4. >> [ ] -1 I am against releasing the packages (must include a reason). >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
[jira] [Updated] (HTTPCLIENT-1877) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1877: - Attachment: stuff.bin [~olegk] Here you are. Thanks > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1877 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1877 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Environment: Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 > Windows 7 Enterprise > Reporter: Philippe Mouawad > Attachments: stuff.bin, wire.txt > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I have previously reported it under > https://issues.apache.org/jira/browse/HTTPCLIENT-1869 and was requested to > provide more details > In the attached log, the issue occurs on second request. > Removing Deflate from Accept-Encoding is a workaround, so issue is located in > Deflate management, GZIP works fine. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1877) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216630#comment-16216630 ] Philippe Mouawad commented on HTTPCLIENT-1877: -- About your question, maybe the misunderstanding comes from the first request in wire, just ignore it in this case. The fact that it works doesn't prove anything. It's just that the demo to reproduce was restricted to those 2 HTTP requests. > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1877 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1877 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Environment: Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 > Windows 7 Enterprise > Reporter: Philippe Mouawad > Attachments: wire.txt > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I have previously reported it under > https://issues.apache.org/jira/browse/HTTPCLIENT-1869 and was requested to > provide more details > In the attached log, the issue occurs on second request. > Removing Deflate from Accept-Encoding is a workaround, so issue is located in > Deflate management, GZIP works fine. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCLIENT-1877) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216626#comment-16216626 ] Philippe Mouawad edited comment on HTTPCLIENT-1877 at 10/24/17 9:50 AM: [~olegk], I don't understand your request. When I first opened the issue with Deflate: - I provided a patch that you refused because it could be too impacting. The patch worked on application for Deflate. You requested me then to provide the wire traffic, as I had written, I don't have access to the application on demand, so I had to wait a bit to have this access and I now create a new issue and provided the wire traffic as I thought you wanted it to analyze the problem and root cause. What did I misunderstand ? Is it that you think there is no bug in HC4 on this item ? If so, I don't think so, as content is correctly decoded by browser with deflate, it only fails when accessed through HttpClient 4.5.3. When we remove Deflate from Accept-Encoding, the response is correctly decoded, but unfortunately as I don't have access to application I cannot attach the wire response, but please believe me on this, why would I be cheating ? What exactly do you want me to provide beside all this ? Thank you Regards was (Author: p.moua...@ubik-ingenierie.com): @Olegk, I don't understand your request. When I first opened the issue with Deflate: - I provided a patch that you refused because it could be too impacting. The patch worked on application for Deflate. You requested me then to provide the wire traffic, as I had written, I don't have access to the application on demand, so I had to wait a bit to have this access and I now create a new issue and provided the wire traffic as I thought you wanted it to analyze the problem and root cause. What did I misunderstand ? Is it that you think there is no bug in HC4 on this item ? If so, I don't think so, as content is correctly decoded by browser with deflate, it only fails when accessed through HttpClient 4.5.3. When we remove Deflate from Accept-Encoding, the response is correctly decoded, but unfortunately as I don't have access to application I cannot attach the wire response, but please believe me on this, why would I be cheating ? What exactly do you want me to provide beside all this ? Thank you Regards > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1877 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1877 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Environment: Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 > Windows 7 Enterprise > Reporter: Philippe Mouawad > Attachments: wire.txt > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I have previously reported it under > https://issues.apache.org/jira/browse/HTT
[jira] [Commented] (HTTPCLIENT-1877) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216626#comment-16216626 ] Philippe Mouawad commented on HTTPCLIENT-1877: -- @Olegk, I don't understand your request. When I first opened the issue with Deflate: - I provided a patch that you refused because it could be too impacting. The patch worked on application for Deflate. You requested me then to provide the wire traffic, as I had written, I don't have access to the application on demand, so I had to wait a bit to have this access and I now create a new issue and provided the wire traffic as I thought you wanted it to analyze the problem and root cause. What did I misunderstand ? Is it that you think there is no bug in HC4 on this item ? If so, I don't think so, as content is correctly decoded by browser with deflate, it only fails when accessed through HttpClient 4.5.3. When we remove Deflate from Accept-Encoding, the response is correctly decoded, but unfortunately as I don't have access to application I cannot attach the wire response, but please believe me on this, why would I be cheating ? What exactly do you want me to provide beside all this ? Thank you Regards > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1877 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1877 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Environment: Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 > Windows 7 Enterprise > Reporter: Philippe Mouawad > Attachments: wire.txt > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I have previously reported it under > https://issues.apache.org/jira/browse/HTTPCLIENT-1869 and was requested to > provide more details > In the attached log, the issue occurs on second request. > Removing Deflate from Accept-Encoding is a workaround, so issue is located in > Deflate management, GZIP works fine. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1877) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216610#comment-16216610 ] Philippe Mouawad commented on HTTPCLIENT-1877: -- Hi [~olegk], Yes my formulation was not clear , the first one is not encoded this way and it works. The first one that comes encoded fails with the stacktrace. Regards > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1877 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1877 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Environment: Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 > Windows 7 Enterprise > Reporter: Philippe Mouawad > Attachments: wire.txt > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I have previously reported it under > https://issues.apache.org/jira/browse/HTTPCLIENT-1869 and was requested to > provide more details > In the attached log, the issue occurs on second request. > Removing Deflate from Accept-Encoding is a workaround, so issue is located in > Deflate management, GZIP works fine. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1877) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1877: - Description: At JMeter project a user has reported an issue that generates this stacktrace : {code:java} java.io.EOFException: Unexpected end of ZLIB input stream at java.util.zip.InflaterInputStream.fill(Unknown Source) at java.util.zip.InflaterInputStream.read(Unknown Source) at org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) at org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) at java.lang.Thread.run(Unknown Source) {code} Although this issue has been reported in the past through https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. I have previously reported it under https://issues.apache.org/jira/browse/HTTPCLIENT-1869 and was requested to provide more details In the attached log, the issue occurs on second request. was: At JMeter project a user has reported an issue that generates this stacktrace : {code:java} java.io.EOFException: Unexpected end of ZLIB input stream at java.util.zip.InflaterInputStream.fill(Unknown Source) at java.util.zip.InflaterInputStream.read(Unknown Source) at org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) at org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) at java.lang.Thread.run(Unknown Source) {code} Although this issue has been reported in the past through https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. I have previously reported it under https://issues.apache.org/jira/browse/HTTPCLIENT-1869 and was requested to provide more details > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1877 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1877 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Environment: Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 > Windows 7 Enterprise > Reporter: Philippe Mouawad > Attachments: wire.txt > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.
[jira] [Created] (HTTPCLIENT-1877) java.io.EOFException: Unexpected end of ZLIB input stream
Philippe Mouawad created HTTPCLIENT-1877: Summary: java.io.EOFException: Unexpected end of ZLIB input stream Key: HTTPCLIENT-1877 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1877 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient (classic) Affects Versions: 4.5.3 Environment: Java HotSpot(TM) 64-Bit Server VM 1.8.0_144 Windows 7 Enterprise Reporter: Philippe Mouawad Attachments: wire.txt At JMeter project a user has reported an issue that generates this stacktrace : {code:java} java.io.EOFException: Unexpected end of ZLIB input stream at java.util.zip.InflaterInputStream.fill(Unknown Source) at java.util.zip.InflaterInputStream.read(Unknown Source) at org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) at org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) at java.lang.Thread.run(Unknown Source) {code} Although this issue has been reported in the past through https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. I have previously reported it under https://issues.apache.org/jira/browse/HTTPCLIENT-1869 and was requested to provide more details -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Releasing HttpCore 4.4.8
Hi Gary, As you're doing the job, I have nothing to say. But IMHO, this is maybe too early. Regards Philippe On Thu, Sep 28, 2017 at 10:08 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Thu, Sep 28, 2017 at 2:03 PM, Philippe Mouawad < > philippe.moua...@gmail.com> wrote: > > > Hello Gary, > > Isn't it too early to release a 4.4.8 ? > > > > What are the new features compared to 4.4.7 ? > > > > This is the current change log: > > > Changelog > --- > > * HTTPCORE-492: Make org.apache.http.nio.protocol.ErrorResponseProducer > public. > Contributed by Gary Gregory > > * HTTPCORE-493: Make > org.apache.http.nio.protocol.HttpAsyncService.responseFactory available to > subclasses. > Contributed by Gary Gregory > > * HTTPCORE-491 Make BasicAsyncRequest|ResponseConsumer more paranoid > Contributed by Michael Heemskerk <mheemsk...@atlassian.com> > > * HTTPCORE-490: session requests do not get cancelled correctly if the > associated HTTP response futures get cancelled > Contributed by Oleg Kalnichevski > > Specifically, I need the top two at work ASAP. > > Gary > > > > Thanks > > > > On Thu, Sep 28, 2017 at 10:00 PM, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > Hi All: > > > > > > I'd like to try my hand at releasing HttpCore 4.4.8 to pick up changes > I > > > need at work. > > > > > > I'll follow https://github.com/ok2c/httpcomponents-release-tools/wiki > > and > > > see what happens... > > > > > > Unless someone objects of course... > > > > > > Gary > > > > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
Re: Releasing HttpCore 4.4.8
Hello Gary, Isn't it too early to release a 4.4.8 ? What are the new features compared to 4.4.7 ? Thanks On Thu, Sep 28, 2017 at 10:00 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > I'd like to try my hand at releasing HttpCore 4.4.8 to pick up changes I > need at work. > > I'll follow https://github.com/ok2c/httpcomponents-release-tools/wiki and > see what happens... > > Unless someone objects of course... > > Gary > -- Cordialement. Philippe Mouawad.
[jira] [Commented] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179642#comment-16179642 ] Philippe Mouawad commented on HTTPCLIENT-1869: -- Hello [~olegk], I was not able yet to obtain raw response yet from my contact. If you want to close it go ahead. I will be proposing a new PR in the upcoming weeks. But frankly [~olegk], you kind of cooled me down with the answers "tone" Of course I don't know HC code as much as you, but I ran Junit test and even the ones you submitted are working for me. Also it seems you just ignore my remark on EOFException while I seriously think this exception can unfortunately be used under "correct" conditions. I thank you for your great and long work on HC , I know it is not always rewarding as it should to do OSS, and I try to be as nice as possible. I thought here that with "colleagues" from same fundation, it would be possible to work together in a nice vibe, I must say I am really disappointed. Good evening and keep up the great work. Regards Philippe > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) > Affects Versions: 4.5.3 >Reporter: Philippe Mouawad >Priority: Minor > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Closed] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad closed HTTPCLIENT-1869. Resolution: Fixed > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Reporter: Philippe Mouawad >Priority: Minor > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173757#comment-16173757 ] Philippe Mouawad commented on HTTPCLIENT-1869: -- [~olegk], Are those tests supposed to fails with my change ? I don't see the class I modified being called. Thanks > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Reporter: Philippe Mouawad >Priority: Minor > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173262#comment-16173262 ] Philippe Mouawad commented on HTTPCLIENT-1869: -- Hello [~olegk], If I was able to provide a reproducer I would, but as I wrote, I don't have access to user platform. I can only attach the wire logging. Is it helpful ? is it enough ? In JMeter 2.13, we used HC4.2.6 and handled gzip and deflate using this: * https://github.com/apache/httpcomponents-client/blob/4.2.x/httpclient/src/main/java/org/apache/http/client/protocol/ResponseContentEncoding.java * https://github.com/apache/jmeter/blob/v2_13/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L669 I'll modify my PR, will you accept it without a reproducer ? Oleg, I understand your position and of course it is always safer to have a test case. But we don't always have this luxury, at least at JMeter I rarely have it. So I hope you can proceed without it. Thanks > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Reporter: Philippe Mouawad >Priority: Minor > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173149#comment-16173149 ] Philippe Mouawad commented on HTTPCLIENT-1869: -- Hi Oleg, Oleg : "So far I have seen no evidence that it is a bug at all, let alone critical." How would you explain then that: - For the same application under test, no issue happens with 4.2.6, while it happens for 4.5.3 - I unfortunately don't have access to the target system, I can attach a log file with debug mode for wire if you're interested. Regarding EOFException, javadoc says this, which IMO can be understood by some developpers that it is a correct way to signal EOF or EO Stream: "This exception is mainly used by data input streams to signal end of stream. Note that many other input operations return a special value on end of stream rather than throwing an exception. " If fix does not suit you, do you expect me to move the catch in DeflateInputStream ? Thanks I hope you can help on this. > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 >Reporter: Philippe Mouawad >Priority: Minor > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173122#comment-16173122 ] Philippe Mouawad commented on HTTPCLIENT-1869: -- Hi [~olegk], I'd like to highlight that while analyzing this issue, I have seen a lot of places where it is faced. IMO, it's a critical bug as it does not allow reading compressed streams with Deflate, for example in JMeter it is blocking some users migration to JMeter 3.x , they stay in 2.13 which relied on httpclient-4.2.6. > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Reporter: Philippe Mouawad >Priority: Critical > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1869: - Priority: Critical (was: Major) > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Reporter: Philippe Mouawad >Priority: Critical > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173105#comment-16173105 ] Philippe Mouawad commented on HTTPCLIENT-1869: -- Hi Oleg, * No issue affects HC4.5.3 using Java 8 last version. I was just mentionning the JDK bug to give an idea about why fix is like that. I'm not applying a workaround here. * Issue affects Deflate not GZIP. * The issue is eof detection which triggers an EOFException for some streams. User who reported the issue confirmed the patch works for him. Regards > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Reporter: Philippe Mouawad > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172213#comment-16172213 ] Philippe Mouawad commented on HTTPCLIENT-1869: -- My fix is based on this : * http://bugs.java.com/bugdatabase/view_bug.do;jsessionid=53ede10dc8803210b03577eac43?bug_id=6519463 > java.io.EOFException: Unexpected end of ZLIB input stream > - > > Key: HTTPCLIENT-1869 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.3 > Reporter: Philippe Mouawad > Fix For: 4.5.4 > > > At JMeter project a user has reported an issue that generates this stacktrace > : > {code:java} > java.io.EOFException: Unexpected end of ZLIB input stream > at java.util.zip.InflaterInputStream.fill(Unknown Source) > at java.util.zip.InflaterInputStream.read(Unknown Source) > at > org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) > at > org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) > at > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) > at > org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) > at > org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) > at > org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Unknown Source) > {code} > Although this issue has been reported in the past through > https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. > I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1869) java.io.EOFException: Unexpected end of ZLIB input stream
Philippe Mouawad created HTTPCLIENT-1869: Summary: java.io.EOFException: Unexpected end of ZLIB input stream Key: HTTPCLIENT-1869 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1869 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient (classic) Affects Versions: 4.5.3 Reporter: Philippe Mouawad Fix For: 4.5.4 At JMeter project a user has reported an issue that generates this stacktrace : {code:java} java.io.EOFException: Unexpected end of ZLIB input stream at java.util.zip.InflaterInputStream.fill(Unknown Source) at java.util.zip.InflaterInputStream.read(Unknown Source) at org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88) at org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:70) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135) at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1814) at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:440) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:433) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178) at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491) at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) at java.lang.Thread.run(Unknown Source) {code} Although this issue has been reported in the past through https://issues.apache.org/jira/browse/HTTPCLIENT-1699 , it is not yet fixed. I'll propose a PR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: [VOTE] Release HttpCore 4.4.7 based on RC1
[+1] Release the packages as HttpCore 4.4.7. Thanks for release On Sun, Sep 10, 2017 at 11:05 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > Please vote on releasing these packages as HttpCore 4.4.7. > The vote is open for the at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Release notes: > https://dist.apache.org/repos/dist/dev/httpcomponents/ > httpcore-4.4.7-RC1/RELEASE_NOTES-4.4.x.txt > > Maven artefacts: > https://repository.apache.org/content/repositories/ > orgapachehttpcomponents-1063/org/apache/httpcomponents/ > > Git Tag: 4.4.7-RC1 > https://github.com/apache/httpcomponents-core/tree/4.4.7-RC1 > > Packages: > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-4.4.7-RC1 > revision 21553 > > Hashes: > 53dd38e2e4621e673e99315add2d21ab httpcomponents-core-4.4.7-src.tar.gz > 988645af25291135c48516ac03fea3ef httpcomponents-core-4.4.7-src.zip > 3f6283deeed23c3e9223c3fbd36f26a1 httpcomponents-core-4.4.7-bin.zip > 913d9aebaeca2b93654a5b70050e4ea3 httpcomponents-core-4.4.7- > osgi-bin.tar.gz > d70d39a51a6ec57309b515ff1bf8b51f httpcomponents-core-4.4.7-bin.tar.gz > 8be72e2cbeb0ed35533978e41de28971 httpcomponents-core-4.4.7-osgi-bin.zip > > Keys: > http://www.apache.org/dist/httpcomponents/httpcore/KEYS > > -- > Vote: HttpCore 4.4.7 release > [ ] +1 Release the packages as HttpCore 4.4.7. > [ ] -1 I am against releasing the packages (must include a reason). > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: HttpCore 5.0: moving to BETA
Bravo Oleg on this ! On Wednesday, August 9, 2017, Oleg Kalnichevski <ol...@apache.org> wrote: > Folks > > I just committed a large chunk of code with the last big feature I had > in mind for the HttpCore 5.0 release. The server side transports (both > classic and async) now provide filter support that can be used to > implement cross-cutting aspects for all incoming requests such the > expect-continue handshake or user authentication and authorization. > > https://github.com/apache/httpcomponents-core/blob/master/httpcore5-tes > ting/src/test/java/org/apache/hc/core5/testing/classic/ClassicAuthentic > ationTest.java > https://github.com/apache/httpcomponents-core/blob/master/httpcore5-tes > ting/src/test/java/org/apache/hc/core5/testing/nio/Http1AuthenticationT > est.java > > Now I would like to shift the focus of development efforts from adding > new features and making disruptive API changes to code stabilization, > API polish and test coverage improvement. I > > _IMPORTANT_: if you would like to make some big API changes: move code > around, rename packages and classes, introduce new naming conventions, > propose new features with a large API footprint _NOW_ would be a good > time to do so. > > @Gary > > You wanted to discuss naming conventions some while ago, did not you? > > It is probably also the right time to discuss whether or not we should > consider building a full featured HTTP server with statement management > (server side cookies), authentication (server side auth schemes), > pluggable user registries, and all those things that used to be out of > project scope. > > I would like to cut another, likely last, ALPHA release soon and > propose moving to the BETA phase. > > Oleg > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@hc.apache.org <javascript:;> > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Git Guidelines (2)
On Tue, May 30, 2017 at 8:55 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Tue, 2017-05-30 at 11:34 -0700, Gary Gregory wrote: > > On Tue, May 30, 2017 at 9:13 AM, Michael Osipov <micha...@apache.org> > > wrote: > > > > > Am 2017-05-29 um 22:54 schrieb Gary Gregory: > > > > > > > On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad < > > > > philippe.moua...@gmail.com> wrote: > > > > > > > > Hello, > > > > > I'm not committer still, my 2 cents: > > > > > > > > > > [x] +1 Committers must abide to these Git guidelines while > > > > > working on the > > > > > code > > > > > > > > > > Except for this one: > > > > > => 1. Request the release manager to merge your banch back to > > > > > the > > > > > release > > > > > branch and make sure that this merge won't incur a merge commit > > > > > > > > > > IMO, this creates a contention on release manager. > > > > > > > > > > > > > > > > > > I'm not a fan of that one. That seems like: > > > > > > > > - a bottleneck for all waiting for the RM to merge. > > > > - an additional burden to the RM > > > > > > > > The text is in contradiction of itself IMO: While "Guidlines" is > > > > in the > > > > title, the boy includes "every committer must abide..." which is > > > > does not > > > > feel like a "guideline". As soon as you enter the "MUST" > > > > territory, do you > > > > need to define what happens if you do not "abide" by the "MUSTs"? > > > > > > > > If these are really guidelines, then all of this is the preferred > > > > way but > > > > all committers are allowed to diverge to get things done. > > > > > > > > > > Gary, why didn't you speak up earlier? > > > > > > Obviously, I was was busy. > > > > > > > I made serveral attempts for the points? > > > > > > We can rename it to Git Rules if you want, so this will be > > > mandatory for > > > all committers. Btw, you recommended to rename to Git Guidelines... > > > > > > Changing the title to "Guidelines" while keeping the intent of strict > > rules > > is misleading. My hope was that my point about using the term > > 'guidelines' > > would trickle down to the actual text, which was obvious to me, and I > > was > > clearly off by not stating my intentions more clearly. I do not > > believe > > that more process and stricter rules will benefit this project, > > especially > > by creating a bottleneck around the RM. But hey, that's just me. > > Since you > > have done (AFAICT) and are currently are doing the bulk of the heavy > > lifting, I am willing to working within your worldview. Sure, I'd > > like to > > see my contributions flow (pun intended) more fluidly (I'm on fire > > today) > > into the code base, but I am happy to live within the confines this > > our > > community defines. > > > > Gary > > > > Gary, Michael, et al > > What if we relax this statement a little by saying that 'a committer > prepares a dev branch, asks RM for a review, and if RM fails to respond > or merge the branch within a, say, 48h window, merges the dev branch > to release branches'? > +1 > > We also say that committers should follow these guidelines to avoid > conflicts instead of abiding them as strict rules? > > Those guidelines that should be strict can be expressed as 'MUST avoid > merge commit', and so on. > > Oleg > > PS: this is why I prefer writing code. > +1 > > > > > > > > > > > Michael > > > > > > > > > On Mon, May 29, 2017 at 9:51 PM, Michael Osipov <micha...@apache.or > > > g> > > > > > wrote: > > > > > > > > > > Am 2017-05-24 um 19:11 schrieb Michael Osipov: > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > > > I am re-casting this vote for the previously discussed Git > > > > > > > guidelines > > > > > > > for all committers to make life easier for everyone. If the > > > > > > > vote > > > > > > > passes, &
Re: [VOTE] Git Guidelines (2)
Hello, I'm not committer still, my 2 cents: [x] +1 Committers must abide to these Git guidelines while working on the code Except for this one: => 1. Request the release manager to merge your banch back to the release branch and make sure that this merge won't incur a merge commit IMO, this creates a contention on release manager. Regards Philippe On Mon, May 29, 2017 at 9:51 PM, Michael Osipov <micha...@apache.org> wrote: > Am 2017-05-24 um 19:11 schrieb Michael Osipov: > >> Hi folks, >> >> I am re-casting this vote for the previously discussed Git guidelines >> for all committers to make life easier for everyone. If the vote passes, >> every committer must abide to this. >> >> The guidelines: >> = Typical Issue Workflow = >> >> 1. Branch off a release branch (e.g., 4.4.x, 5.0.x) ({{{git checkout -b >> / master}}}) where {{{}}} being the >> JIRA issue you have assigned to yourself, e.g., HTTPCORE-123 or >> HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-123 4.4.x}}}. >> 1. Work on your issue and create as many commits as you want/need >> 1. Polish it, squash it or fix it up into a single commit >> 1. Ask for a review if you are uncertain >> 1. Take care of a proper commit message (good reads: >> [[https://chris.beams.io/posts/git-commit/|1]] and >> [[https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]): >> Put the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in >> response, in the first line, followed by an explanation why you did take >> this approach. The ticket desc contains the issue, your commit message >> contains the solution. If in doubt, ask for help and give people a >> couple of days to react. >> 1. Request the release manager to merge your banch back to the release >> branch and make sure that this merge won't incur a merge commit >> 1. When you close the issue, put a link to your commit to create a >> direct relation between issue and solution. >> >> = Side Notes = >> >> 1. Never rewrite (rebase) history on master or any other long-lived >> branch because you will break others. Only the release manager is >> entitled to clean up history upto 72 hours after a commit if it is >> absolutely necessary >> 1. If a change comes for a PR on GitHub: >>* Apply the same above rules >>* Don't steal authorship >>* Let the reporter polish his work >>* Amend the message at the end with "This closes/fixes #xy" and push. >> >> >> Link: https://wiki.apache.org/HttpComponents/GitGuidelines >> >> Vote is open until 2017-05-29 00:00 Etc/UTC. >> > > Folks, > > vote is over and no one except Oleg and me has voted. > > What now? Will chaos reign our Git repos? > > > Michael > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: [VOTE][Simple Majority] Migrate project source repository to Git
Hello, [X] +1 I am in favor of migration to Git Regards On Sunday, May 7, 2017, i...@flyingfischer.ch <i...@flyingfischer.ch> wrote: > [X] +1 I am in favor of migration to Git > [ ] -1 I am against migration to Git (must include a reason). > > Markus > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@hc.apache.org <javascript:;> > > -- Cordialement. Philippe Mouawad.
[jira] [Commented] (HTTPCLIENT-1664) Migrate away from Commons Logging to SLF4J
[ 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
[ 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
Re: [VOTE] Release HttpCore 5.0-alpha3 based on RC1
[X] +1 Release the packages as HttpCore 5.0-alpha3. Kudos for your work on support of HTTP2 Regards On Saturday, April 29, 2017, i...@flyingfischer.ch <i...@flyingfischer.ch> wrote: > -- > > Vote: HttpCore 5.0-alpha3 release > > [X] +1 Release the packages as HttpCore 5.0-alpha3. > > [ ] -1 I am against releasing the packages (must include a reason). > > > Markus > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@hc.apache.org <javascript:;> > > -- Cordialement. Philippe Mouawad.
Re: User-Agent
Hi, Add Httpmime also ? Regards On Wed, Feb 15, 2017 at 10:19 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > Hi All: > > Right now our user agent logs as: > > User-Agent: Apache-HttpClient/4.5.2 (Java/1.7.0_80) > > I think this would be more helpful when debugging: > > User-Agent: Apache-HttpClient/4.5.2 Apache-HttpCore/4.4.5 Java/1.7.0_80 > > Thoughts? > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <https://www.amazon.com/gp/product/1617290459/ref=as_li_ > tl?ie=UTF8=1789=9325=1617290459& > linkCode=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1= > 1617290459> > JUnit in Action, Second Edition > <https://www.amazon.com/gp/product/1935182021/ref=as_li_ > tl?ie=UTF8=1789=9325=1935182021& > linkCode=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22 > > > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1= > 1935182021> > Spring Batch in Action > <https://www.amazon.com/gp/product/1935182951/ref=as_li_ > tl?ie=UTF8=1789=9325=1935182951& > linkCode=%7B%7BlinkCode%7D%7D=garygregory-20=%7B% > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1= > 1935182951> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpAsyncClient 4.1.3 based on RC1
[X] +1 Release the packages as HttpAsyncClient 4.1.3. Thanks for your work ! On Sunday, February 5, 2017, Oleg Kalnichevski <ol...@apache.org> wrote: > Please vote on releasing these packages as HttpAsyncClient 4.1.3. > The vote is open for the at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Release notes: > https://dist.apache.org/repos/dist/dev/httpcomponents/ > httpasyncclient-4.1.3-RC1/RELEASE_NOTES-4.1.x.txt > > Maven artefacts: > https://repository.apache.org/content/repositories/ > orgapachehttpcomponents-1055/org/apache/httpcomponents/httpasyncclient > > SVN tag: > https://svn.apache.org/repos/asf/httpcomponents/ > httpasyncclient/tags/4.1.3-RC1 > revision 1781751 > > Packages: > https://dist.apache.org/repos/dist/dev/httpcomponents/ > httpasyncclient-4.1.3-RC1 > revision 18143 > > Hashes: > 58b47a6015b92220ee39858a32be76dc httpcomponents-asyncclient-4. > 1.3-bin.tar.gz > 22edac0508eb0eecf5ae45e3029fced5 httpcomponents-asyncclient-4. > 1.3-osgi-bin.tar.gz > 847ea3bcad47659d5b31964780252ae5 httpcomponents-asyncclient-4. > 1.3-src.tar.gz > b083e9183dcc6c57ba64d07a18ac6f55 httpcomponents-asyncclient-4.1.3-bin.zip > 937b86a03eec9435757ed0e105e225b0 httpcomponents-asyncclient-4. > 1.3-osgi-bin.zip > 0e18d4a81b11cbafd1a4cb65f67d2069 httpcomponents-asyncclient-4.1.3-src.zip > > Keys: > http://www.apache.org/dist/httpcomponents/httpasyncclient/KEYS > > -- > Vote: HttpAsyncClient 4.1.3 release > [ ] +1 Release the packages as HttpAsyncClient 4.1.3. > [ ] -1 I am against releasing the packages (must include a reason). > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@hc.apache.org <javascript:;> > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpCore 5.0-alpha2 based on RC1 (updated)
Hello, Congrats on the HTTP2 support ! [+1] Release the packages as HttpCore 5.0-alpha2. (not binding) Regards On Wed, Dec 21, 2016 at 8:51 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Wed, 2016-12-21 at 11:05 -0800, Gary Gregory wrote: > > Hi, > > > > Based on src zip, MD5 OK, ASC OK (no SHA1). > > > > RAT check failures: > > > > > > E:/temp/rc/httpcomponents-core-5.0-alpha2/httpcore5- > testing-compat/docker/apache-httpd/.dockerignore > > > > E:/temp/rc/httpcomponents-core-5.0-alpha2/httpcore5- > testing-compat/docker/nginx/.dockerignore > > > > These should be ignored explicitly in the POM or fixed. > > > > They already are. See > > https://github.com/apache/httpcore/blob/5.0-alpha2-RC1/pom.xml#L327 > > I am not sure what else I am supposed to do here. > > Oleg > > > > Gary > > > > > > On Wed, Dec 21, 2016 at 10:53 AM, Oleg Kalnichevski <ol...@apache.org> > > wrote: > > > > > Please vote on releasing these packages as HttpCore 5.0-alpha2. > > > The vote is open for the at least 72 hours, and only votes from > > > HttpComponents PMC members are binding. The vote passes if at least > > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > > > Release notes: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/ > > > httpcore-5.0-alpha2-RC1/RELEASE_NOTES-5.0.x.txt > > > > > > Maven artefacts: > > > https://repository.apache.org/content/repositories/ > > > orgapachehttpcomponents-1051/org/apache/httpcomponents/core5/ > > > > > > SVN tag: > > > https://svn.apache.org/repos/asf/httpcomponents/httpcore/ > > > tags/5.0-alpha2-RC1 > > > revision 1774888 > > > > > > Packages: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/ > > > httpcore-5.0-alpha2-RC1 > > > revision 17513 > > > > > > Hashes: > > > 590f4234f7af72ef61297c7e332a0058 httpcomponents-core-5.0- > > > alpha2-bin.tar.gz > > > 9ca9e4e7db427121cf70b2c454b9b651 httpcomponents-core-5.0- > > > alpha2-osgi-bin.tar.gz > > > c9969ff7c005040c57a928467ef3997e httpcomponents-core-5.0- > > > alpha2-src.tar.gz > > > 783ce95788a02c4dbf582cdb4b2f80a1 httpcomponents-core-5.0- > alpha2-bin.zip > > > e489e2d5202d6ead8ad609702ac3778b httpcomponents-core-5.0- > > > alpha2-osgi-bin.zip > > > ae948ace8084e9f5482f96f971b0b480 httpcomponents-core-5.0- > alpha2-src.zip > > > > > > Keys: > > > http://www.apache.org/dist/httpcomponents/httpcore/KEYS > > > > > > > -- > > > Vote: HttpCore 5.0-alpha2 release > > > [ ] +1 Release the packages as HttpCore 5.0-alpha2. > > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpAsyncClient 4.1.2 based on RC2
+1 Release the packages as HttpAsyncClient 4.1.2. On Sunday, June 19, 2016, Oleg Kalnichevski <ol...@apache.org> wrote: > [x] +1 Release the packages as HttpAsyncClient 4.1.2 > > On Sat, 2016-06-18 at 15:01 +0200, Oleg Kalnichevski wrote: > > Please vote on releasing these packages as HttpAsyncClient 4.1.2. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpasyncclient-4.1.2-RC2/RELEASE_NOTES-4.1.x.txt > > > > Maven artefacts: > > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1046/org/apache/httpcomponents/ > > > > SVN tag: > > > https://svn.apache.org/repos/asf/httpcomponents/httpasyncclient/tags/4.1.2-RC2 > > revision 1748985 > > > > Packages: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpasyncclient-4.1.2-RC2 > > revision 14037 > > > > Hashes: > > 1173c5a59d1477ac9e7036d2391a81a4 > httpcomponents-asyncclient-4.1.2-bin.tar.gz > > d79bf67f10fc60e8e8f20e4fd6f312c3 > httpcomponents-asyncclient-4.1.2-osgi-bin.tar.gz > > 1ebb383bc2499d22a0627e4f85d60bbe > httpcomponents-asyncclient-4.1.2-src.tar.gz > > 63a689c797fda22ce3b5db329905ee7c > httpcomponents-asyncclient-4.1.2-bin.zip > > cfe0de7a9ad620094e215501292d9a6a > httpcomponents-asyncclient-4.1.2-osgi-bin.zip > > 4c6f146fd82a84a856faf67ca498a1ac > httpcomponents-asyncclient-4.1.2-src.zip > > > > Keys: > > http://www.apache.org/dist/httpcomponents/httpasyncclient/KEYS > > > > > -- > > Vote: HttpAsyncClient 4.1.2 release > > [ ] +1 Release the packages as HttpAsyncClient 4.1.2. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org <javascript:;> > > For additional commands, e-mail: dev-h...@hc.apache.org <javascript:;> > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@hc.apache.org <javascript:;> > > -- Cordialement. Philippe Mouawad.
Re: [VOTE] Release HttpCore 4.4.5 based on RC1
+1 Release the packages as HttpCore 4.4.5. On Thu, Jun 9, 2016 at 7:12 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > +1: > > But this test should be adjusted to work on Windows: > > Tests run: 13, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.3 sec > <<< FAILURE! - in org.apache.http.ssl.TestSSLContextBuilder > > testSSLHanskshakeProtocolMismatch2(org.apache.http.ssl.TestSSLContextBuilder) > Time elapsed: 0.02 sec <<< ERROR! > java.lang.Exception: Unexpected exception, > expected but > was > at java.net.SocketInputStream.socketRead0(Native Method) > at > java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) > at sun.security.ssl.InputRecord.read(InputRecord.java:503) > at > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) > at > > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) > at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) > at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387) > at > > org.apache.http.ssl.TestSSLContextBuilder.testSSLHanskshakeProtocolMismatch2(TestSSLContextBuilder.java:603) > > I fixed this in trunk a while back but I did not back-port the change to > all the branches. > > MD5 and ASC are OK. There is no SHA1 (which I see on all Commons RCs for > example.) > > RAT check OK. > > Clirr check OK. > > Aggregate Javadoc generation builds OK and looks OK. > > PDF builds OK and looks OK. > > Gary > > > > > On Wed, Jun 8, 2016 at 9:50 AM, Oleg Kalnichevski <ol...@apache.org> > wrote: > > > Please vote on releasing these packages as HttpCore 4.4.5. > > The vote is open for the at least 72 hours, and only votes from > > HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Release notes: > > > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-4.4.5-RC1/RELEASE_NOTES-4.4.x.txt > > > > Maven artefacts: > > > > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1044/org/apache/httpcomponents/ > > > > SVN tag: > > https://svn.apache.org/repos/asf/httpcomponents/httpcore/tags/4.4.5-RC1 > > revision 1747417 > > > > Packages: > > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-4.4.5-RC1 > > revision 13940 > > > > Hashes: > > 5a5f3790cdbc357d920a3993de93aa62 httpcomponents-core-4.4.5-bin.tar.gz > > df1199e8fce6dc49c2e27b45ea6d53d3 > httpcomponents-core-4.4.5-osgi-bin.tar.gz > > 5c34e513845b8879c2a557c1b44a69d5 httpcomponents-core-4.4.5-src.tar.gz > > eb31a30148c82b893335f0115c3e81c0 httpcomponents-core-4.4.5-bin.zip > > bb9b871fa0c57fba99458e43a4d26c6d httpcomponents-core-4.4.5-osgi-bin.zip > > 6b3d3110544b684d9895a1df5ca7e672 httpcomponents-core-4.4.5-src.zip > > > > Keys: > > http://www.apache.org/dist/httpcomponents/httpcore/KEYS > > > > > -- > > Vote: HttpCore 4.4.5 release > > [ ] +1 Release the packages as HttpCore 4.4.5. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Cordialement. Philippe Mouawad.
[jira] [Commented] (HTTPCLIENT-1742) No connection reuse if response is compressed
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280711#comment-15280711 ] Philippe Mouawad commented on HTTPCLIENT-1742: -- Hi [~olegk], [~rainer.j...@kippdata.de], The issue is indeed due to this line of code in JMeter: ((AbstractHttpClient) httpClient).addResponseInterceptor(new org.apache.http.client.protocol.ResponseContentEncoding()); What happens is what Rainer described: ResponseContentEncoding removes the 3 headers related to compression (Content-Encoding, Content-Length, Content-MD5) then keeplive is called , as the Content-Length is no more there, we end up not keeping alive the connection. It didn't happen in JMeter 2.13, because previous version of HttpClient did not touch these 3 headers. It happens now in JMeter 3.0 as we rely on HC 4.5.2 which does. I am investigating on why this does not happen with your sample. > No connection reuse if response is compressed > - > > Key: HTTPCLIENT-1742 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1742 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.2 > Environment: Linux, Java 8 >Reporter: Rainer Jung > > Trying current JMeter trunk I ran into a problem, that connections were not > being reused. Debugging into it revealed IMHO a HttpClient/HttpCore problem. > Below you'll find a wire dump of the response headers: > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "HTTP/1.1 200 > OK[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Date: Tue, 10 May 2016 > 20:44:15 GMT[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Server: Apache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma: > no-cache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control: > no-cache, no-store, must-revalidate[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma: > no-cache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control: > no-cache, no-store, must-revalidate[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma: > no-cache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control: > no-cache, no-store, must-revalidate[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Vary: > Accept-Encoding[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Encoding: > gzip[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << > "X-Content-Type-Options: nosniff[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "X-Frame-Options: > sameorigin[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Length: > 1194[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Keep-Alive: > timeout=60, max=[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Connection: > Keep-Alive[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Type: > text/html;charset=utf-8[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << HTTP/1.1 200 OK > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Date: Tue, 10 May > 2016 20:44:15 GMT > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Server: Apache > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Pragma: no-cache > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Cache-Control: > no-cache, no-store, must-revalidate > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Expires: 0 > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Pragma: no-cache > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Cache-Control: > no-cache, no-store, must-revalidate > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Expires: 0 > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Pra
[jira] [Comment Edited] (HTTPCLIENT-1742) No connection reuse if response is compressed
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280711#comment-15280711 ] Philippe Mouawad edited comment on HTTPCLIENT-1742 at 5/11/16 8:05 PM: --- Hi [~olegk], [~rainer.j...@kippdata.de], The issue is indeed due to this line of code in JMeter: ((AbstractHttpClient) httpClient).addResponseInterceptor(new org.apache.http.client.protocol.ResponseContentEncoding()); What happens is what Rainer described: ResponseContentEncoding removes the 3 headers related to compression (Content-Encoding, Content-Length, Content-MD5) then keeplive is called , as the Content-Length is no more there, we end up not keeping alive the connection. It didn't happen in JMeter 2.13, because previous version of HttpClient did not touch these 3 headers. It happens now in JMeter 3.0 as we rely on HC 4.5.2 which does. There is no bug in HttpClient as JMeter is using DefaultRequestDirector which is deprecated . The processing in @olegk sample is very different, it uses MainClientExec which first manages keepalive and only after that manages the response. was (Author: pmouawad): Hi [~olegk], [~rainer.j...@kippdata.de], The issue is indeed due to this line of code in JMeter: ((AbstractHttpClient) httpClient).addResponseInterceptor(new org.apache.http.client.protocol.ResponseContentEncoding()); What happens is what Rainer described: ResponseContentEncoding removes the 3 headers related to compression (Content-Encoding, Content-Length, Content-MD5) then keeplive is called , as the Content-Length is no more there, we end up not keeping alive the connection. It didn't happen in JMeter 2.13, because previous version of HttpClient did not touch these 3 headers. It happens now in JMeter 3.0 as we rely on HC 4.5.2 which does. I am investigating on why this does not happen with your sample. > No connection reuse if response is compressed > - > > Key: HTTPCLIENT-1742 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1742 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.2 > Environment: Linux, Java 8 >Reporter: Rainer Jung > > Trying current JMeter trunk I ran into a problem, that connections were not > being reused. Debugging into it revealed IMHO a HttpClient/HttpCore problem. > Below you'll find a wire dump of the response headers: > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "HTTP/1.1 200 > OK[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Date: Tue, 10 May 2016 > 20:44:15 GMT[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Server: Apache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma: > no-cache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control: > no-cache, no-store, must-revalidate[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma: > no-cache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control: > no-cache, no-store, must-revalidate[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Pragma: > no-cache[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Cache-Control: > no-cache, no-store, must-revalidate[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Expires: 0[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Vary: > Accept-Encoding[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Encoding: > gzip[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << > "X-Content-Type-Options: nosniff[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "X-Frame-Options: > sameorigin[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Length: > 1194[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Keep-Alive: > timeout=60, max=[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Connection: > Keep-Alive[\r][\n]" > 2016/05/10 22:44:15 DEBUG - org.apache.http.wire: << "Content-Type: > text/html;charset=utf-8[\r][\n]" > 2016/05/10 22:44:15 DEBUG - o
[jira] [Commented] (HTTPCLIENT-1739) repeated calls to HttpClients.custom.build take longer over time
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15256827#comment-15256827 ] Philippe Mouawad commented on HTTPCLIENT-1739: -- [~racarlson] can you please reopen this JIRA ? It is understandable that you don't have time to compile, but you may understand that Apache HttpClient volunteers (who often work on the personal time) ask you "if possible" to provide a self contained and compilable test. Your response looks a bit "rude" to me but ok, just reopen it and it will be investigated and at least help others. Thanks for your report anyway. > repeated calls to HttpClients.custom.build take longer over time > > > Key: HTTPCLIENT-1739 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1739 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.2 > Environment: windows xp 32 bit, windows 7 64 bit and RedHat > enterprise 7. Tested on Web Server > apache-tomee-plus-1.7.1/apache-tomee-plus-1.7.4 deployed as @Webservice's > calling external webservices using httpclient >Reporter: Ralph Carlson >Priority: Minor > > (Tested on latest version and version 4.3 and both have same issue.) > repeated calls to HttpClients.custom.build take longer over time. Tested > using http library in webservice that calls and outside webservice. Initially > HttpClients.custom.build run quickly for first several hundred, then takes > increasingly longer to create client despite all objects clean up as per api > spec each request. Some cache or code in the api takes longer and longer to > create the client and no api methods exposed that can change this, only > solution now was to create a Map to cache HttpClients so not creating new > ones and look up HttpClient you need based on input parameters. > sample code that when called over and over again creates the issue: > {code:java} > protected static CloseableHttpClient > _getCloseableHttpClient(HttpClientToolsInput input) throws Exception > { //method >//--- you can cache these object as static final > since never change and still get the same result , included here as example > code for bug > SSLContextBuilder sslContextBuilder = > SSLContexts.custom(); > sslContextBuilder.loadTrustMaterial(null, new > TrustStrategy() > { > public boolean > isTrusted(X509Certificate[] chain, String authType) throws > CertificateException { return true; } > @Override public boolean > isTrusted(java.security.cert.X509Certificate[] chain,String authType) throws > CertificateException { return true; } > }); > SSLContext sslContext = sslContextBuilder.build(); > > SSLConnectionSocketFactory sslConnectionSocketFactory = > new SSLConnectionSocketFactory( sslContext, new String[] {"TLSv1", "TLSv1.1", > "TLSv1.2"},null,new HostnameVerifier() > { > public void verify(String host, > X509Certificate cert) throws SSLException { } > @Override public boolean verify(String s, > SSLSession sslSession) { > return true; > } > }); > > Registry socketFactoryRegistry > = > > RegistryBuilder. create().register("http", > PlainConnectionSocketFactory.INSTANCE).register("https", > sslConnectionSocketFactory).build(); > SSLConnectionSocketFactory sslsf = new > SSLConnectionSocketFactory(sslContextBuilder.build()); > //--- you can cache these object as static final : > end > //--- these objects below are created and > clean up each request > BasicHttpClientConnectionManager cm = new > BasicHttpClientConnectionManager(socketFactoryRegistry); > RequestConfig defaultRequestConfig = > RequestConfig.custom().setSocketTimeout( > > input.getSocketTimeout()).setConnectTimeout( >
[jira] [Updated] (HTTPCLIENT-1730) PoolingHttpClientConnectionManager: Expose validateAfterInactivity (defaults to 2000ms) and improve javadocs
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1730: - Summary: PoolingHttpClientConnectionManager: Expose validateAfterInactivity (defaults to 2000ms) and improve javadocs (was: Improve PoolingHttpClientConnectionManager javadocs) > PoolingHttpClientConnectionManager: Expose validateAfterInactivity (defaults > to 2000ms) and improve javadocs > > > Key: HTTPCLIENT-1730 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1730 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpClient >Affects Versions: 5.0 Alpha1 > Reporter: Philippe Mouawad >Priority: Minor > Labels: documentation > Fix For: Future > > > As per mailing list discussion: > "Question about PoolingHttpClientConnectionManager#timeToLive" > Improve the javadocs of the component -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1730) Improve PoolingHttpClientConnectionManager javadocs
Philippe Mouawad created HTTPCLIENT-1730: Summary: Improve PoolingHttpClientConnectionManager javadocs Key: HTTPCLIENT-1730 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1730 Project: HttpComponents HttpClient Issue Type: Improvement Components: HttpClient Affects Versions: 5.0 Alpha1 Reporter: Philippe Mouawad Priority: Minor Fix For: Future As per mailing list discussion: "Question about PoolingHttpClientConnectionManager#timeToLive" Improve the javadocs of the component -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: [VOTE] Release HttpClient 4.5.2 based on RC1
+1 Release the packages as HttpClient 4.5.2 On Sunday, February 21, 2016, Oleg Kalnichevski <ol...@apache.org> wrote: > Please vote on releasing these packages as HttpClient 4.5.2. > The vote is open for the at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Release notes: > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.2-RC1/RELEASE_NOTES-4.5.x.txt > > Maven artefacts: > > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1043/org/apache/httpcomponents/ > > SVN tag: > https://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.5.2-RC1 > revision 1731537 > > Packages: > > https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.5.2-RC1 > revision 12481 > > Hashes: > a802b03b9973bd80bc69b34cb126ce4e httpcomponents-client-4.5.2-bin.tar.gz > e27a338be7e8d1186b32af5161cc54eb > httpcomponents-client-4.5.2-osgi-bin.tar.gz > 36fae919b6f26a7f65aa51b0af389775 httpcomponents-client-4.5.2-src.tar.gz > 4ae99f942aefecc51a19fd97111eb1b5 httpcomponents-client-4.5.2-bin.zip > cac3fc9c010e11fb588a5a279ea496e0 httpcomponents-client-4.5.2-osgi-bin.zip > 9d786e6641367ccfbec27d48087f5dff httpcomponents-client-4.5.2-src.zip > > Keys: > http://www.apache.org/dist/httpcomponents/httpclient/KEYS > > -- > Vote: HttpClient 4.5.2 release > [ ] +1 Release the packages as HttpClient 4.5.2. > [ ] -1 I am against releasing the packages (must include a reason). > > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@hc.apache.org <javascript:;> > > -- Cordialement. Philippe Mouawad.
[jira] [Resolved] (HTTPCLIENT-1723) HttpClient 4.5.1 may perform multiple requests on the same connection despite having "Connection: close" header.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad resolved HTTPCLIENT-1723. -- Resolution: Fixed Fixed by commit this commit: http://svn.apache.org/viewvc?rev=1722952=rev > HttpClient 4.5.1 may perform multiple requests on the same connection despite > having "Connection: close" header. > > > Key: HTTPCLIENT-1723 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1723 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 >Reporter: Philippe Mouawad > Fix For: 4.5.2 > > > This issue is the same as HTTPCORE-397. > But the fix for 4.5.2 is in HttpClient not HttpCore to avoid a new release of > HttpCore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1723) HttpClient 4.5.1 may perform multiple requests on the same connection despite having "Connection: close" header.
Philippe Mouawad created HTTPCLIENT-1723: Summary: HttpClient 4.5.1 may perform multiple requests on the same connection despite having "Connection: close" header. Key: HTTPCLIENT-1723 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1723 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5.1 Reporter: Philippe Mouawad Fix For: 4.5.2 This issue is the same as HTTPCORE-397. But the fix for 4.5.2 is in HttpClient not HttpCore to avoid a new release of HttpCore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1704) CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1704: - Fix Version/s: 4.5.2 > CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true > -- > > Key: HTTPCLIENT-1704 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1704 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1, Snapshot > Reporter: Philippe Mouawad >Priority: Trivial > Fix For: 4.5.2, 5.0 Alpha1 > > Attachments: httpclient.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of org.apache.http.client.config.CookieSpec#match > compared to org.apache.commons.httpclient.cookie.CookieSpec#match. > In HC3, match returned false for IGNORE_POLICY while it now returns true. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity and org.apache.http.entity.mime.content.StringBody
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15155156#comment-15155156 ] Philippe Mouawad commented on HTTPCLIENT-1665: -- Thank you [~garydgregory] ! > Regression in org.apache.http.entity.mime.MultipartEntity and > org.apache.http.entity.mime.content.StringBody > -- > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad >Priority: Trivial > Labels: regression > Fix For: 4.5.2 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity and org.apache.http.entity.mime.content.StringBody
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15155116#comment-15155116 ] Philippe Mouawad commented on HTTPCLIENT-1665: -- Hi [~garydgregory], @Olegk, The fix is at line 108: {code:java} @Deprecated public StringBody( final String text, final String mimeType, final Charset charset) throws UnsupportedEncodingException { this(text, ContentType.create(mimeType, charset != null ? charset : Consts.ASCII)); } {code} > Regression in org.apache.http.entity.mime.MultipartEntity and > org.apache.http.entity.mime.content.StringBody > -- > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad >Priority: Trivial > Labels: regression > Fix For: 4.5.2 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity and org.apache.http.entity.mime.content.StringBody
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15154960#comment-15154960 ] Philippe Mouawad commented on HTTPCLIENT-1665: -- Hi [~olegk], I checked out 4.5.X branch tonight and tests show we also have an issue with StringBody. Constructor documentation says : {code:none} @param charset the character set, may be {@code null}, in which case the US-ASCII charset is used {code} But it appears US-ASCII is not used. For info: [~s...@apache.org] [~fschumacher] [~rjung] > Regression in org.apache.http.entity.mime.MultipartEntity and > org.apache.http.entity.mime.content.StringBody > -- > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad >Priority: Trivial > Labels: regression > Fix For: 4.5.2 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Reopened] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity and org.apache.http.entity.mime.content.StringBody
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad reopened HTTPCLIENT-1665: -- > Regression in org.apache.http.entity.mime.MultipartEntity and > org.apache.http.entity.mime.content.StringBody > -- > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad >Priority: Trivial > Labels: regression > Fix For: 4.5.2 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity and org.apache.http.entity.mime.content.StringBody
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1665: - Summary: Regression in org.apache.http.entity.mime.MultipartEntity and org.apache.http.entity.mime.content.StringBody (was: Regression in org.apache.http.entity.mime.MultipartEntity) > Regression in org.apache.http.entity.mime.MultipartEntity and > org.apache.http.entity.mime.content.StringBody > -- > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad >Priority: Trivial > Labels: regression > Fix For: 4.5.2 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-397) HttpClient 4.4.1 may perform multiple requests on the same connection despite having "Connection: close" header.
[ https://issues.apache.org/jira/browse/HTTPCORE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081712#comment-15081712 ] Philippe Mouawad commented on HTTPCORE-397: --- Thanks a lot [~olegk] ! Do you have some date on release of HttpClient 4.5.2 ? > HttpClient 4.4.1 may perform multiple requests on the same connection despite > having "Connection: close" header. > > > Key: HTTPCORE-397 > URL: https://issues.apache.org/jira/browse/HTTPCORE-397 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore >Affects Versions: 4.4.1 >Reporter: Alan Silva >Priority: Minor > Fix For: 5.0-alpha1 > > > Question originally posted in Stack Overflow > [here|http://stackoverflow.com/questions/29523143/apache-httpclient-4-x-302-redirects-with-keepalive-off]. > Answered by [~olegk]. > The quick summary of the question and its resolution: > My use case involved a request to a server whose response back was a 302 > redirect using non-persistence on the connection. > The current implementation of the HttpClient on version 4.4.1 GA will > implicitly launch a follow-up request to the path specified in the "location" > header path from the 302 response. The problem is, when the httpclient is > sent with the "Connection: close" header, it is not aware of having done so. > The result is that, if the server responds *WITHOUT* a corresponding > "Connection: close", the client will assume the connection must be kept > alive, and perform the next request for the redirect path on the same > connection. This obviously leads to a problem since the server will have > closed the socket on its end of the connection by now. > The problem was ultimately fixed by forcing the server to send a "Connection: > close" header in response to the HttpClient's "Connection:close". However, > according to the HTTP 1.1 spec, the server is not obliged to do this, > although, it should. http://tools.ietf.org/html/rfc2616#section-8: > {code} > An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to >maintain a persistent connection unless a Connection header including >the connection-token "close" was sent in the request. If the server >chooses to close the connection immediately after sending the >response, it SHOULD send a Connection header including the >connection-token close. > {code} > However, on the client side, the rules on the matter are stricter. > {code} > Persistent connections provide a mechanism by which a client and a >server can signal the close of a TCP connection. This signaling takes >place using the Connection header field (section 14.10). Once a close >has been signaled, the client MUST NOT send any more requests on that >connection. > {code} > Ideally, there should be a way for the HttpClient to realize it has announced > its intention to close the connection via the "Connection: close" header, and > stop itself from sending any more requests on the connection, without outside > intervention from the server it's communicating with. > This issue was not observed in HttpClient 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-397) HttpClient 4.4.1 may perform multiple requests on the same connection despite having "Connection: close" header.
[ https://issues.apache.org/jira/browse/HTTPCORE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076599#comment-15076599 ] Philippe Mouawad commented on HTTPCORE-397: --- Hi [~olegk], Yes it would be nice to commit it and have it along with HttpClient 4.5.2 / HttpCore 4.4.5 as we have some pending bug on it that we would like to fix for next version. For record: - https://bz.apache.org/bugzilla/show_bug.cgi?id=58583 Thanks > HttpClient 4.4.1 may perform multiple requests on the same connection despite > having "Connection: close" header. > > > Key: HTTPCORE-397 > URL: https://issues.apache.org/jira/browse/HTTPCORE-397 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore >Affects Versions: 4.4.1 >Reporter: Alan Silva >Priority: Minor > Fix For: 5.0-alpha1 > > > Question originally posted in Stack Overflow > [here|http://stackoverflow.com/questions/29523143/apache-httpclient-4-x-302-redirects-with-keepalive-off]. > Answered by [~olegk]. > The quick summary of the question and its resolution: > My use case involved a request to a server whose response back was a 302 > redirect using non-persistence on the connection. > The current implementation of the HttpClient on version 4.4.1 GA will > implicitly launch a follow-up request to the path specified in the "location" > header path from the 302 response. The problem is, when the httpclient is > sent with the "Connection: close" header, it is not aware of having done so. > The result is that, if the server responds *WITHOUT* a corresponding > "Connection: close", the client will assume the connection must be kept > alive, and perform the next request for the redirect path on the same > connection. This obviously leads to a problem since the server will have > closed the socket on its end of the connection by now. > The problem was ultimately fixed by forcing the server to send a "Connection: > close" header in response to the HttpClient's "Connection:close". However, > according to the HTTP 1.1 spec, the server is not obliged to do this, > although, it should. http://tools.ietf.org/html/rfc2616#section-8: > {code} > An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to >maintain a persistent connection unless a Connection header including >the connection-token "close" was sent in the request. If the server >chooses to close the connection immediately after sending the >response, it SHOULD send a Connection header including the >connection-token close. > {code} > However, on the client side, the rules on the matter are stricter. > {code} > Persistent connections provide a mechanism by which a client and a >server can signal the close of a TCP connection. This signaling takes >place using the Connection header field (section 14.10). Once a close >has been signaled, the client MUST NOT send any more requests on that >connection. > {code} > Ideally, there should be a way for the HttpClient to realize it has announced > its intention to close the connection via the "Connection: close" header, and > stop itself from sending any more requests on the connection, without outside > intervention from the server it's communicating with. > This issue was not observed in HttpClient 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-397) HttpClient 4.4.1 may perform multiple requests on the same connection despite having "Connection: close" header.
[ https://issues.apache.org/jira/browse/HTTPCORE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076703#comment-15076703 ] Philippe Mouawad commented on HTTPCORE-397: --- Hi [~olegk], Yes this should be OK for us. Thanks a lot. > HttpClient 4.4.1 may perform multiple requests on the same connection despite > having "Connection: close" header. > > > Key: HTTPCORE-397 > URL: https://issues.apache.org/jira/browse/HTTPCORE-397 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore >Affects Versions: 4.4.1 >Reporter: Alan Silva >Priority: Minor > Fix For: 5.0-alpha1 > > > Question originally posted in Stack Overflow > [here|http://stackoverflow.com/questions/29523143/apache-httpclient-4-x-302-redirects-with-keepalive-off]. > Answered by [~olegk]. > The quick summary of the question and its resolution: > My use case involved a request to a server whose response back was a 302 > redirect using non-persistence on the connection. > The current implementation of the HttpClient on version 4.4.1 GA will > implicitly launch a follow-up request to the path specified in the "location" > header path from the 302 response. The problem is, when the httpclient is > sent with the "Connection: close" header, it is not aware of having done so. > The result is that, if the server responds *WITHOUT* a corresponding > "Connection: close", the client will assume the connection must be kept > alive, and perform the next request for the redirect path on the same > connection. This obviously leads to a problem since the server will have > closed the socket on its end of the connection by now. > The problem was ultimately fixed by forcing the server to send a "Connection: > close" header in response to the HttpClient's "Connection:close". However, > according to the HTTP 1.1 spec, the server is not obliged to do this, > although, it should. http://tools.ietf.org/html/rfc2616#section-8: > {code} > An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to >maintain a persistent connection unless a Connection header including >the connection-token "close" was sent in the request. If the server >chooses to close the connection immediately after sending the >response, it SHOULD send a Connection header including the >connection-token close. > {code} > However, on the client side, the rules on the matter are stricter. > {code} > Persistent connections provide a mechanism by which a client and a >server can signal the close of a TCP connection. This signaling takes >place using the Connection header field (section 14.10). Once a close >has been signaled, the client MUST NOT send any more requests on that >connection. > {code} > Ideally, there should be a way for the HttpClient to realize it has announced > its intention to close the connection via the "Connection: close" header, and > stop itself from sending any more requests on the connection, without outside > intervention from the server it's communicating with. > This issue was not observed in HttpClient 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-397) HttpClient 4.4.1 may perform multiple requests on the same connection despite having "Connection: close" header.
[ https://issues.apache.org/jira/browse/HTTPCORE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076350#comment-15076350 ] Philippe Mouawad commented on HTTPCORE-397: --- Hi [~olegk] I have submitted a PR for 4.4.x: https://github.com/apache/httpcore/pull/19 It works for our need on JMeter but it is not complete as context.getAttribute(HttpCoreContext.HTTP_REQUEST); in some call paths. Can we add without risk the call to localContext.setAttribute(HttpCoreContext.HTTP_REQUEST, HttpRequest ) before keepAlive calls or could it introduce issues ? Thanks > HttpClient 4.4.1 may perform multiple requests on the same connection despite > having "Connection: close" header. > > > Key: HTTPCORE-397 > URL: https://issues.apache.org/jira/browse/HTTPCORE-397 > Project: HttpComponents HttpCore > Issue Type: Bug > Components: HttpCore >Affects Versions: 4.4.1 >Reporter: Alan Silva >Priority: Minor > Fix For: 5.0-alpha1 > > > Question originally posted in Stack Overflow > [here|http://stackoverflow.com/questions/29523143/apache-httpclient-4-x-302-redirects-with-keepalive-off]. > Answered by [~olegk]. > The quick summary of the question and its resolution: > My use case involved a request to a server whose response back was a 302 > redirect using non-persistence on the connection. > The current implementation of the HttpClient on version 4.4.1 GA will > implicitly launch a follow-up request to the path specified in the "location" > header path from the 302 response. The problem is, when the httpclient is > sent with the "Connection: close" header, it is not aware of having done so. > The result is that, if the server responds *WITHOUT* a corresponding > "Connection: close", the client will assume the connection must be kept > alive, and perform the next request for the redirect path on the same > connection. This obviously leads to a problem since the server will have > closed the socket on its end of the connection by now. > The problem was ultimately fixed by forcing the server to send a "Connection: > close" header in response to the HttpClient's "Connection:close". However, > according to the HTTP 1.1 spec, the server is not obliged to do this, > although, it should. http://tools.ietf.org/html/rfc2616#section-8: > {code} > An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to >maintain a persistent connection unless a Connection header including >the connection-token "close" was sent in the request. If the server >chooses to close the connection immediately after sending the >response, it SHOULD send a Connection header including the >connection-token close. > {code} > However, on the client side, the rules on the matter are stricter. > {code} > Persistent connections provide a mechanism by which a client and a >server can signal the close of a TCP connection. This signaling takes >place using the Connection header field (section 14.10). Once a close >has been signaled, the client MUST NOT send any more requests on that >connection. > {code} > Ideally, there should be a way for the HttpClient to realize it has announced > its intention to close the connection via the "Connection: close" header, and > stop itself from sending any more requests on the connection, without outside > intervention from the server it's communicating with. > This issue was not observed in HttpClient 4.2.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Closed] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad closed HTTPCLIENT-1705. Resolution: Not A Problem Thanks a lot [~olegk] > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch, TestCookieOrdering.java > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060769#comment-15060769 ] Philippe Mouawad commented on HTTPCLIENT-1705: -- Hi [~olegk], Sorry again, I made a mistake in my test, the line with Cookie Origin should be: {code:java} this.cookieOrigin = new CookieOrigin("order.now", 80, "/sub1/moo.html", false); {code} Test fails with: {code:none} org.junit.ComparisonFailure: expected:<test[2=moo2; test1=moo1; test2=moo3]> but was:<test[1=moo1; test2=moo3; test2=moo2]> at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.apache.http.client.protocol.TestCookieOrdering.testOrdering(TestCookieOrdering.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) {code} > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient > Affects Versions: 4.5.1 >Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch, TestCookieOrdering.java, > TestCookieOrdering.java > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1705: - Attachment: TestCookieOrdering.java > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch, TestCookieOrdering.java, > TestCookieOrdering.java > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1705: - Attachment: (was: TestCookieOrdering.java) > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch, TestCookieOrdering.java > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1705: - Attachment: TestCookieOrdering.java > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch, TestCookieOrdering.java > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Reopened] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad reopened HTTPCLIENT-1705: -- I fixed my test and still have issue when using Default Policy. See attached test class > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1704) CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15056233#comment-15056233 ] Philippe Mouawad commented on HTTPCLIENT-1704: -- Hi @olegk, Why not commit also the test case ? Thanks > CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true > -- > > Key: HTTPCLIENT-1704 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1704 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1, Snapshot > Reporter: Philippe Mouawad >Priority: Trivial > Fix For: 4.5.2, 5.0 > > Attachments: httpclient.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of org.apache.http.client.config.CookieSpec#match > compared to org.apache.commons.httpclient.cookie.CookieSpec#match. > In HC3, match returned false for IGNORE_POLICY while it now returns true. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Closed] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad closed HTTPCLIENT-1705. Resolution: Invalid Thanks for looking at it. > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15056284#comment-15056284 ] Philippe Mouawad commented on HTTPCLIENT-1705: -- Sorry [~olegk], mixed up with another case. I will close it. > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1704) CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15056255#comment-15056255 ] Philippe Mouawad commented on HTTPCLIENT-1704: -- Ok [~olegk], will try to. Sorry but it was my first look at httpclient code and wanted to go fast. I think my following tests were a bit better but always looking to improve. Regards > CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true > -- > > Key: HTTPCLIENT-1704 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1704 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1, Snapshot > Reporter: Philippe Mouawad >Priority: Trivial > Fix For: 4.5.2, 5.0 > > Attachments: httpclient.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of org.apache.http.client.config.CookieSpec#match > compared to org.apache.commons.httpclient.cookie.CookieSpec#match. > In HC3, match returned false for IGNORE_POLICY while it now returns true. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1706) Domain starting with "." in a cookie makes CookieSpec#match fails for subdomain
Philippe Mouawad created HTTPCLIENT-1706: Summary: Domain starting with "." in a cookie makes CookieSpec#match fails for subdomain Key: HTTPCLIENT-1706 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1706 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5.1 Reporter: Philippe Mouawad Following: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E When migrating from HTTPCLIENT3 to HC4.5.1 (issue is also in HC4.2.3), we have an issue in behaviour of RFC6265 org.apache.http.client.config.CookieSpec Following test fails: {code:java} @Test public void testDomainStartingWithDot() { final BasicClientCookie cookie1 = new BasicClientCookie("id", "value"); cookie1.setPath("/"); cookie1.setDomain(".apache.org"); cookie1.setSecure(false); cookie1.setExpiryDate(new Date(99L)); URL url; try { url = new URL("http://jakarta.apache.org/index.html;); String host = url.getHost(); int port= 80; String path = url.getPath(); boolean isSecure=false; CookieOrigin cookieOrigin = new CookieOrigin(host, port, path, isSecure); PublicSuffixMatcher publicSuffixMatcher = PublicSuffixMatcherLoader.getDefault(); Registry registry = RegistryBuilder.create() .register(CookieSpecs.STANDARD, new RFC6265CookieSpecProvider(publicSuffixMatcher)) .build(); HttpClientContext context = HttpClientContext.create(); CookieSpec cookieSpec = registry.lookup(CookieSpecs.STANDARD).create(context); Assert.assertTrue(cookieSpec.match(cookie1, cookieOrigin)); } catch (MalformedURLException e) { Assert.fail(e.getMessage()); } } {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1704) CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1704: - Attachment: httpclient.patch Patch with test method to understand what I am talking about > CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true > -- > > Key: HTTPCLIENT-1704 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1704 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1, Snapshot > Reporter: Philippe Mouawad > Attachments: httpclient.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of org.apache.http.client.config.CookieSpecs#match > compared to org.apache.commons.httpclient.cookie.CookieSpec#match. > In HC3, match returned false for IGNORE_POLICY while it now returns true. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1705: - Attachment: HTTPCLIENT-1705.patch Patch with a test case > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpecs#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
Philippe Mouawad created HTTPCLIENT-1705: Summary: CookieSpecs#formatCookies ordering change between HC3 and HC4 Key: HTTPCLIENT-1705 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5.1 Reporter: Philippe Mouawad Following: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have a change in behaviour of org.apache.http.client.config.CookieSpecs#formatCookies compared to org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15055154#comment-15055154 ] Philippe Mouawad commented on HTTPCLIENT-1705: -- Hi [~olegk], I am not an HTTP specialist as you are so I may be wrong, but I read "Cookies with longer paths are listed before cookies with shorter paths." , so I think there is a bug. But, reading https://tools.ietf.org/html/rfc6265#5.4: {code:none} The user agent SHOULD sort the cookie-list in the following order: * Cookies with longer paths are listed before cookies with shorter paths. * Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times. NOTE: Not all user agents sort the cookie-list in this order, but this order reflects common practice when this document was written, and, historically, there have been servers that (erroneously) depended on this order. {code} > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 >Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1701) Building.txt mentions Java6+ but project requires Java7
Philippe Mouawad created HTTPCLIENT-1701: Summary: Building.txt mentions Java6+ but project requires Java7 Key: HTTPCLIENT-1701 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1701 Project: HttpComponents HttpClient Issue Type: Bug Components: Documentation Affects Versions: Snapshot Reporter: Philippe Mouawad -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1702) Running mvn eclipse:eclipse fails with Maven 3.2.3 due to an issue with httpmime
Philippe Mouawad created HTTPCLIENT-1702: Summary: Running mvn eclipse:eclipse fails with Maven 3.2.3 due to an issue with httpmime Key: HTTPCLIENT-1702 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1702 Project: HttpComponents HttpClient Issue Type: Bug Components: Documentation Affects Versions: Snapshot Reporter: Philippe Mouawad [ERROR] Failed to execute goal on project httpmime: Could not resolve dependencies for project org.apache.httpcomponents:httpmime:jar:5.0-alpha1-SNAPSHOT: Could not find artifact org.apache.httpcomponents:httpclient:jar:5.0-alpha1-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project httpmime: Could not resolve dependencies for project org.apache.httpcomponents:httpmime:jar:5.0-alpha1-SNAPSHOT: Could not find artifact org.apache.httpcomponents:httpclient:jar:5.0-alpha1-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:220) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project org.apache.httpcomponents:httpmime:jar:5.0-alpha1-SNAPSHOT: Could not find artifact org.apache.httpcomponents:httpclient:jar:5.0-alpha1-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:198) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195) ... 22 more Caused by: org.eclipse.aether.resolution.DependencyResolutionException: Could not find artifact org.apache.httpcomponents:httpclient:jar:5.0-alpha1-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:384) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:192) ... 23 more Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.apache.httpcomponents:httpclient:jar:5.0-alpha1-SNAPSHOT in apache.snapshots (http://repository.apache.org/snapshots) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:459) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:262) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:367) ... 24 more Cau
[jira] [Updated] (HTTPCLIENT-1704) CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1704: - Description: Following: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have a change in behaviour of org.apache.http.client.config.CookieSpec#match compared to org.apache.commons.httpclient.cookie.CookieSpec#match. In HC3, match returned false for IGNORE_POLICY while it now returns true. was: Following: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have a change in behaviour of org.apache.http.client.config.CookieSpecs#match compared to org.apache.commons.httpclient.cookie.CookieSpec#match. In HC3, match returned false for IGNORE_POLICY while it now returns true. > CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true > -- > > Key: HTTPCLIENT-1704 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1704 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1, Snapshot > Reporter: Philippe Mouawad > Attachments: httpclient.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of org.apache.http.client.config.CookieSpec#match > compared to org.apache.commons.httpclient.cookie.CookieSpec#match. > In HC3, match returned false for IGNORE_POLICY while it now returns true. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1705) CookieSpecs#formatCookies ordering change between HC3 and HC4
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1705: - Description: Following: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have a change in behaviour of org.apache.http.client.config.CookieSpec#formatCookies compared to org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. was: Following: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have a change in behaviour of org.apache.http.client.config.CookieSpecs#formatCookies compared to org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. > CookieSpecs#formatCookies ordering change between HC3 and HC4 > - > > Key: HTTPCLIENT-1705 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1705 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient >Affects Versions: 4.5.1 > Reporter: Philippe Mouawad > Attachments: HTTPCLIENT-1705.patch > > > Following: > http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E > When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have > a change in behaviour of > org.apache.http.client.config.CookieSpec#formatCookies compared to > org.apache.commons.httpclient.cookie.CookieSpec#formatCookies. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1704) CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true
Philippe Mouawad created HTTPCLIENT-1704: Summary: CookieSpecs.IGNORE_COOKIE policy CookieSpec#match returns true Key: HTTPCLIENT-1704 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1704 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.5.1, Snapshot Reporter: Philippe Mouawad Attachments: httpclient.patch Following: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201512.mbox/%3CCAH9fUpYn6BDFUMA6qq-q4ioFsSQvd%2BFrLJCiSJXaAxnw1ZsBtg%40mail.gmail.com%3E When migrating from HTTPCLIENT3 to HC4.5 (issue is also in HC4.2.3), we have a change in behaviour of org.apache.http.client.config.CookieSpecs#match compared to org.apache.commons.httpclient.cookie.CookieSpec#match. In HC3, match returned false for IGNORE_POLICY while it now returns true. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971742#comment-14971742 ] Philippe Mouawad commented on HTTPCLIENT-1665: -- HI Oleg, Well we have a lot of work on JMeter and migration is not that easy. We will migrate surely, but if you can help us on this it would be great. What would be nice for anybody using httpclient/core/mime, is when you deprecate a class to mention how and which classes should be used instead. And to have some documentation explaining how to migrate. Regards Philippe > Regression in org.apache.http.entity.mime.MultipartEntity > - > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad >Priority: Trivial > Labels: regression > Fix For: 4.5.2 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14969871#comment-14969871 ] Philippe Mouawad commented on HTTPCLIENT-1665: -- Hello Oleg, Thanks a lot for your fix. When is 4.5.2 release planned ? Thanks > Regression in org.apache.http.entity.mime.MultipartEntity > - > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad >Priority: Trivial > Labels: regression > Fix For: 4.5.2 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Reopened] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad reopened HTTPCLIENT-1665: -- Hi Oleg, Sorry for late reply. We face the issue when upgrading JMeter libraries from 4.2.6 to 4.5.1 and running the junit tests in JMeter https://github.com/apache/jmeter/blob/trunk/test/src/org/apache/jmeter/protocol/http/sampler/TestHTTPSamplersAgainstHttpMirrorServer.java Failure is: {code:text} [java] Time: 72.39 [java] There were 2 failures: [java] 1) testPostRequest_FormMultipart3(org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer)junit.framework.AssertionFailedError: arrays have different length, expected is 402, actual is 366 [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkArraysHaveSameContent(TestHTTPSamplersAgainstHttpMirrorServer.java:1240) [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkPostRequestFormMultipart(TestHTTPSamplersAgainstHttpMirrorServer.java:831) [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FormMultipart(TestHTTPSamplersAgainstHttpMirrorServer.java:342) [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FormMultipart3(TestHTTPSamplersAgainstHttpMirrorServer.java:153) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [java] at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) [java] at junit.extensions.TestSetup$1.protect(TestSetup.java:23) [java] at junit.extensions.TestSetup.run(TestSetup.java:27) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236) [java] 2) testPostRequest_FileUpload3(org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer)junit.framework.AssertionFailedError: arrays have different length, expected is 677, actual is 641 [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkArraysHaveSameContent(TestHTTPSamplersAgainstHttpMirrorServer.java:1240) [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.checkPostRequestFileUpload(TestHTTPSamplersAgainstHttpMirrorServer.java:893) [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FileUpload(TestHTTPSamplersAgainstHttpMirrorServer.java:441) [java] at org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServer.testPostRequest_FileUpload3(TestHTTPSamplersAgainstHttpMirrorServer.java:165) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [java] at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23) [java] at junit.extensions.TestSetup$1.protect(TestSetup.java:23) [java] at junit.extensions.TestSetup.run(TestSetup.java:27) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236) [java] FAILURES!!! {code} Some contributor has fixed it this way: https://github.com/redline13/jmeter/commit/6fbf9933aff1a2cca29e7ecc6c8b08e102514ce7#diff-4e3471b25c91730a99ed23402467b9eaR997 But is this regular ? Thanks Regards > Regression in org.apache.http.entity.mime.MultipartEntity > - > > Key: HTTPCLIENT-1665 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpMime >Affects Versions: 4.5 > Reporter: Philippe Mouawad > Labels: regression > Fix For: 4.5.1 > > > As per org.apache.http.entity.mime.MultipartEntity constructor documentation: > > @param charset the character set to use, may be {@code null}, in which case > > {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. > But it appears that in 4.5 version, if null is passed then no charset part is > written. > The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1665) Regression in org.apache.http.entity.mime.MultipartEntity
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1665: - Description: As per org.apache.http.entity.mime.MultipartEntity constructor documentation: @param charset the character set to use, may be {@code null}, in which case {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. But it appears that in 4.5 version, if null is passed then no charset part is written. The same issue exists for FormBodyPart. was: As per org.apache.http.entity.mime.MultipartEntity constructor documentation: @param charset the character set to use, may be {@code null}, in which case {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. But it appears that in 4.5 version, if null is passed then no charset part is written. The same issue exists for StringEntity. Regression in org.apache.http.entity.mime.MultipartEntity - Key: HTTPCLIENT-1665 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1665 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpMime Affects Versions: 4.5 Reporter: Philippe Mouawad Labels: regression Fix For: 4.5.1 As per org.apache.http.entity.mime.MultipartEntity constructor documentation: @param charset the character set to use, may be {@code null}, in which case {@link MIME#DEFAULT_CHARSET} - i.e. US-ASCII - is used. But it appears that in 4.5 version, if null is passed then no charset part is written. The same issue exists for FormBodyPart. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1343) Provide a configuration option to simplify the socket initialization process for enabled protocols
Philippe Mouawad created HTTPCLIENT-1343: Summary: Provide a configuration option to simplify the socket initialization process for enabled protocols Key: HTTPCLIENT-1343 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1343 Project: HttpComponents HttpClient Issue Type: Improvement Components: HttpClient Affects Versions: 4.3 Beta1, 4.2.5 Reporter: Philippe Mouawad Fix For: Future Mailing list discussion: http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201304.mbox/%3C1366022529.26739.14.camel%40ubuntu%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1302) AllowAllHostnameVerifier should not access session
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558373#comment-13558373 ] Philippe Mouawad commented on HTTPCLIENT-1302: -- But javadocs says: * The ALLOW_ALL HostnameVerifier essentially turns hostname verification * off. This implementation is a no-op, and never throws the SSLException. In our case, requests hangs for 4-5 seconds for each request when using IP's without reverse DNS AllowAllHostnameVerifier should not access session -- Key: HTTPCLIENT-1302 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1302 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.3 Reporter: Philippe Mouawad Fix For: 4.2.4 Hello, We are facing a bug in JMeter: - https://issues.apache.org/bugzilla/show_bug.cgi?id=54449 Analyzing code, I noticed AllowAllHostnameVerifier ends up calling AbstractVerifier#verify(String host, SSLSocket ssl) which does more job than it should for AllowAllHostname policy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1302) AllowAllHostnameVerifier should not access session
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558382#comment-13558382 ] Philippe Mouawad commented on HTTPCLIENT-1302: -- But issue is not related to this it seems after further investigation. Sorry for annoyance AllowAllHostnameVerifier should not access session -- Key: HTTPCLIENT-1302 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1302 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.3 Reporter: Philippe Mouawad Fix For: 4.2.4 Hello, We are facing a bug in JMeter: - https://issues.apache.org/bugzilla/show_bug.cgi?id=54449 Analyzing code, I noticed AllowAllHostnameVerifier ends up calling AbstractVerifier#verify(String host, SSLSocket ssl) which does more job than it should for AllowAllHostname policy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Closed] (HTTPCLIENT-1302) AllowAllHostnameVerifier should not access session
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad closed HTTPCLIENT-1302. Resolution: Invalid AllowAllHostnameVerifier should not access session -- Key: HTTPCLIENT-1302 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1302 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.3 Reporter: Philippe Mouawad Fix For: 4.2.4 Hello, We are facing a bug in JMeter: - https://issues.apache.org/bugzilla/show_bug.cgi?id=54449 Analyzing code, I noticed AllowAllHostnameVerifier ends up calling AbstractVerifier#verify(String host, SSLSocket ssl) which does more job than it should for AllowAllHostname policy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1286) HttpClient treats URI fragments in redirect URIs inconsistently
Philippe Mouawad created HTTPCLIENT-1286: Summary: HttpClient treats URI fragments in redirect URIs inconsistently Key: HTTPCLIENT-1286 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1286 Project: HttpComponents HttpClient Issue Type: Bug Reporter: Philippe Mouawad HttpClient treats URI fragments in redirect URIs incosistently. It strips fragments from relative URIs but leaves absolute ones unchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1286) HttpClient treats URI fragments in redirect URIs inconsistently
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1286: - Component/s: HttpClient Affects Version/s: 4.2.2 HttpClient treats URI fragments in redirect URIs inconsistently --- Key: HTTPCLIENT-1286 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1286 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.2 Reporter: Philippe Mouawad HttpClient treats URI fragments in redirect URIs incosistently. It strips fragments from relative URIs but leaves absolute ones unchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1286) HttpClient treats URI fragments in redirect URIs inconsistently
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1286: - Attachment: BUG_54351.jmx redirect.jsp JSP to put in tomcat6 in folder: webapps/examples/jsp. Test plan showing issue with JMeter 2.8 (embeds HttpClient 4.2.1) Issue still here with JMeter current nightly build which embeds HttpClient 4.2.2. Issue only happens with HC4, not HC3.1 or Java HttpClient treats URI fragments in redirect URIs inconsistently --- Key: HTTPCLIENT-1286 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1286 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.2 Reporter: Philippe Mouawad Attachments: BUG_54351.jmx, redirect.jsp HttpClient treats URI fragments in redirect URIs incosistently. It strips fragments from relative URIs but leaves absolute ones unchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1286) HttpClient treats URI fragments in URIs inconsistently
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1286: - Summary: HttpClient treats URI fragments in URIs inconsistently (was: HttpClient treats URI fragments in redirect URIs inconsistently) HttpClient treats URI fragments in URIs inconsistently -- Key: HTTPCLIENT-1286 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1286 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.2 Reporter: Philippe Mouawad Attachments: BUG_54351.jmx, redirect.jsp HttpClient treats URI fragments in redirect URIs incosistently. It strips fragments from relative URIs but leaves absolute ones unchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1286) HttpClient treats URI fragments in URIs inconsistently
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541377#comment-13541377 ] Philippe Mouawad commented on HTTPCLIENT-1286: -- It seems just calling URL like this http://localhost:8080/examples/jsp/index.html#toto fails due to fragment. It does not with Java or HC3.1 Impls HttpClient treats URI fragments in URIs inconsistently -- Key: HTTPCLIENT-1286 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1286 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.2 Reporter: Philippe Mouawad Attachments: BUG_54351.jmx, redirect.jsp HttpClient treats URI fragments in redirect URIs incosistently. It strips fragments from relative URIs but leaves absolute ones unchanges. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-1234) HTTPS + SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER leads to javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Philippe Mouawad created HTTPCLIENT-1234: Summary: HTTPS + SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER leads to javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated Key: HTTPCLIENT-1234 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1234 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient Affects Versions: 4.2.1 Reporter: Philippe Mouawad Hello, We got a report of an issue with JMeter: http://stackoverflow.com/questions/12538233/javax-net-ssl-sslpeerunverifiedexception-peer-not-authenticated-when-load-testi The reporter has setup a public site with his configuration: https://ec2-50-17-85-212.compute-1.amazonaws.com:8443/hello/ I reproduced issue with JMeter but it seems it comes from HttpClient or it's a feature. I created a simple test class I attach here not related to JMeter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org