[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
[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
[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/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
[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.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:88)
[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
[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
[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
[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: << 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: << Vary: Accept-Encoding > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << Content-Encoding: gzip > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << > X-Content-Type-Options: nosniff > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: << X-Frame-Options: > sameorigin > 2016/05/10 22:44:15 DEBUG - org.apache.http.headers: <<
[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 - 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 >
[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(
>
> input.getConnectionTimeout()).setConnectionRequestTimeout(
>
> input.getConnectionRequestTimeout()).build();
> // get same bug if modify code to use
> different client other than CloseableHttpClient
>
[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
[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:
but was:
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 Caused
[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
[jira] [Updated] (HTTPCLIENT-1234) HTTPS + SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER leads to javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Mouawad updated HTTPCLIENT-1234: - Attachment: WebClientDevWrapper.java Reference is here: http://javaskeleton.blogspot.fr/2010/07/avoiding-peer-not-authenticated-with.html Note that solution using custom X509HostnameVerifier leads to Connection Reset by peer while page displays correctly in Browser after accepting certificate exception. 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 Attachments: WebClientDevWrapper.java 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
[jira] [Commented] (HTTPCLIENT-1234) HTTPS + SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER leads to javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461397#comment-13461397 ] Philippe Mouawad commented on HTTPCLIENT-1234: -- See also: https://issues.apache.org/bugzilla/show_bug.cgi?id=53922 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 Attachments: WebClientDevWrapper.java 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
[jira] [Commented] (HTTPCLIENT-1234) HTTPS + SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER leads to javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461459#comment-13461459 ] Philippe Mouawad commented on HTTPCLIENT-1234: -- Note it also happens without SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER and on a valid site: http://www.sslshopper.com/ssl-checker.html#hostname=https://load.axonify.com:8443/hello Note that tomcat connector has some specific configuration, see SO. 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 Attachments: WebClientDevWrapper.java 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
