H2RequesterBootstrap vs CloseableHttpAsyncClient

[Philippe Mouawad]

Hello,
I hope you're all fine.

Is it possible to clarify the difference and expected use cases for those 2
classes ?

   - H2RequesterBootstrap as available in examples (
   
https://github.com/apache/httpcomponents-core/blob/42f79d433e79eb9d31e01df1e65f763828a3721f/httpcore5-testing/src/main/java/org/apache/hc/core5/benchmark/HttpBenchmark.java
   )
   - CloseableHttpAsyncClient as illustrated here
  -
  
http://hc.apache.org/httpcomponents-client-5.0.x/migration-guide/migration-to-async-http2.html

I guess the first one is lower level but I am a bit confused by their
respective target

Thanks
-- 
Regards
Philippe M.

Re: Migration from HC4 to HC5 : few questions

[Philippe Mouawad]

Hello Oleg,
Sorry for late reply, this mail was in my drafts, while I thought I had
sent it.

*Thank you for your detailed answers and rapid feedback.*
All this helps a lot !

Regarding HttpConnectionMetrics, since we need metrics per request and not
per connection, my understanding is that we would need a reset method, do I
understand well ?
Regards
Philippe


On Thu, Jun 11, 2020 at 12:35 PM Oleg Kalnichevski  wrote:

> On Wed, 2020-06-10 at 19:11 +0200, Philippe Mouawad wrote:
> > Hello,
> > I am looking into migrating Apache JMeter project from HC4 to HC5 to
> > benefit from the new features for Classic  HttpClient like the new
> > lax
> > connection pool and performance improvements.
> > In the future we would hopefully switch to Async.
> >
> > First thanks for this documentation, very useful ! :
> >
> https://ok2c.github.io/httpclient-migration-guide/migration-to-classic.html
> >
> > Few questions:
> >
> >1. I don't see an equivalent of
> > RequestConfig.Builder#setLocalAddress ?
> >How do we get this feature ?
>
>  RequestConfig.Builder#setLocalAddress was a mistake. This parameter
> has nothing to do with request execution.
>
> Please use custom HttpRoutePlanner instead.
>
>
> >2. Is there an equivalent of LaxRedirectStrategy?  or
> >DefaultRedirectStrategy is now the equivalent which seems to be
> > the case ?
>
> DefaultRedirectStrategy should now cover all common cases. Lax strategy
> implementation is now superfluous.
>
>
> >3.
> >
> >PoolingHttpClientConnectionManager does not expose anymore the
> >HttpClientConnectionOperator, it's a protected constructor. In
> > JMeter we
> >use this to compute connect time. It looks like we would need to
> > extend
> >PoolingHttpClientConnectionManager, is there another better way to
> > keep
> >this ?
>
>
> No, this is the intended way.
>
>
> >4.
> >
> >Regarding bandwidth measurement per request, we used this approach
> > based
> >on your SO answer (
> >
> >
> https://stackoverflow.com/questions/26166469/measure-bandwidth-usage-with-apache-httpcomponents-httpclient
> >):
> >
> >
> >-
> >
> >
> https://github.com/apache/jmeter/blob/master/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L448
> >   - Is it still ok using
> >
> >   preProcess/postProcess by redefining them in an extension of
> >   HttpRequestExecutor and access endpointdetails through:
> >   -
> >
> >   HttpCoreContext.*adapt*(context).getEndpointDetails();
> >
> >   But I don't see any more reset(), so how should we proceed ?
> >
> >
>
> There is no #reset method. We could add but I am not sure if you really
> need it at all. If you need the total bytes sent / received and the
> total number of requests / responses those details are provided by
> HttpConnectionMetrics interface.
>
> Hope this helps
>
> Oleg
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Migration from HC4 to HC5 : few questions

[Philippe Mouawad]

Hello,
I am looking into migrating Apache JMeter project from HC4 to HC5 to
benefit from the new features for Classic  HttpClient like the new lax
connection pool and performance improvements.
In the future we would hopefully switch to Async.

First thanks for this documentation, very useful ! :
https://ok2c.github.io/httpclient-migration-guide/migration-to-classic.html

Few questions:

   1. I don't see an equivalent of RequestConfig.Builder#setLocalAddress ?
   How do we get this feature ?
   2. Is there an equivalent of LaxRedirectStrategy?  or
   DefaultRedirectStrategy is now the equivalent which seems to be the case ?
   3.

   PoolingHttpClientConnectionManager does not expose anymore the
   HttpClientConnectionOperator, it's a protected constructor. In JMeter we
   use this to compute connect time. It looks like we would need to extend
   PoolingHttpClientConnectionManager, is there another better way to keep
   this ?
   4.

   Regarding bandwidth measurement per request, we used this approach based
   on your SO answer (
   
https://stackoverflow.com/questions/26166469/measure-bandwidth-usage-with-apache-httpcomponents-httpclient
   ):


   -
  
https://github.com/apache/jmeter/blob/master/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L448
  - Is it still ok using

  preProcess/postProcess by redefining them in an extension of
  HttpRequestExecutor and access endpointdetails through:
  -

  HttpCoreContext.*adapt*(context).getEndpointDetails();

  But I don't see any more reset(), so how should we proceed ?



Thanks for your help.

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Release HTTP Client 4.5.7 not available on maven repository

[Philippe Mouawad]

Hello,
Thanks for the release 4.5.7.

There seem to be an issue with publication to Maven Central, it is not
available:

   - https://repo1.maven.org/maven2/org/apache/httpcomponents/httpclient/


Regards

Re: [ANNOUNCEMENT] HttpComponents Client 4.5.7 GA Released

[Philippe Mouawad]

Thanks for this release.

It appears 4.5.7 artifact was not published on Maven.

Regards

On Thu, Jan 24, 2019 at 10:34 PM Oleg Kalnichevski  wrote:

> The Apache HttpComponents project is pleased to announce 4.5.7 GA
> release of HttpComponents HttpClient.
>
> This is a maintenance release that corrects Automatic-Module-Name
> definitions added in the previous release and fixes a number of minor
> defects discovered since 4.5.6.
>
> Download - <http://hc.apache.org/downloads.cgi>
> Release notes -
> <https://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.
> 5.x.txt>
> HttpComponents site - <http://hc.apache.org/>
>
> About HttpComponents HttpClient
>
> The Hyper-Text Transfer Protocol (HTTP) is perhaps the most significant
> protocol used on the Internet today. Web services, network-enabled
> appliances and the growth of network computing continue to expand the
> role of the HTTP protocol beyond user-driven web browsers, while
> increasing the number of applications that require HTTP support.
>
> Although the java.net package provides basic functionality for
> accessing resources via HTTP, it doesn't provide the full flexibility
> or functionality needed by many applications. HttpClient seeks to fill
> this void by providing an efficient, up-to-date, and feature-rich
> package implementing the client side of the most recent HTTP standards
> and recommendations.
>
> Designed for extension while providing robust support for the base HTTP
> protocol, HttpClient may be of interest to anyone building HTTP-aware
> client applications such as web browsers, web service clients, or
> systems that leverage or extend the HTTP protocol for distributed
> communication.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Release date for httpclient 4.5.7

[Philippe Mouawad]

Hello Oleg,
Great !
Thank you for taking into account our feedback !

Regards

On Thu, Jan 10, 2019 at 9:58 AM Oleg Kalnichevski  wrote:

> On Tue, 2019-01-08 at 08:19 -0500, Gary Gregory wrote:
> > Hi Phillip,
> >
> > I think Oleg will be best to answer this one.
> >
> > Gary
> >
>
> Philippe
>
> I will likely be working on HttpCore 4.4.11 this weekend. HttpClient
> 4.5.7 can happen around Jan 20th.
>
> Oleg
>
>
> > On Fri, Jan 4, 2019 at 2:33 PM Philippe Mouawad <
> > philippe.moua...@gmail.com>
> > wrote:
> >
> > > Hello,
> > > Happy new year 2019 to the team !
> > >
> > > Thanks for answer.
> > > Any chance to release before end of january ?
> > >
> > > Regards
> > >
> > > On Thu, Dec 20, 2018 at 10:51 AM Oleg Kalnichevski <
> > > ol...@apache.org>
> > > wrote:
> > >
> > > > On Wed, 2018-12-19 at 10:10 +0100, Philippe Mouawad wrote:
> > > > > Hello,
> > > > >
> > > > > We have a bug in JMeter which requires availibility of
> > > > > httpclient
> > > > > 4.5.7.
> > > > > Since we'd like to release soon a new version, is there a
> > > > > visibility
> > > > > on the
> > > > > future release of 4.5.7 ?
> > > > >
> > > > > Thank you
> > > > > Regards
> > > >
> > > > Likely Q1 2019
> > > >
> > > > Oleg
> > > >
> > > >
> > >
> > > --
> > > Cordialement.
> > > Philippe Mouawad.
> > >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Release date for httpclient 4.5.7

[Philippe Mouawad]

Hello,
Happy new year 2019 to the team !

Thanks for answer.
Any chance to release before end of january ?

Regards

On Thu, Dec 20, 2018 at 10:51 AM Oleg Kalnichevski  wrote:

> On Wed, 2018-12-19 at 10:10 +0100, Philippe Mouawad wrote:
> > Hello,
> >
> > We have a bug in JMeter which requires availibility of httpclient
> > 4.5.7.
> > Since we'd like to release soon a new version, is there a visibility
> > on the
> > future release of 4.5.7 ?
> >
> > Thank you
> > Regards
>
> Likely Q1 2019
>
> Oleg
>
>

-- 
Cordialement.
Philippe Mouawad.

Release date for httpclient 4.5.7

[Philippe Mouawad]

Hello,

We have a bug in JMeter which requires availibility of httpclient 4.5.7.
Since we'd like to release soon a new version, is there a visibility on the
future release of 4.5.7 ?

Thank you
Regards

Re: Issue with Proxy / keep alive , getting NoHttpResponseException after a failed request

[Philippe Mouawad]

Hello Oleg,
Thanks for your help, I confirm it works.

So issue would be in JMeter Recorder.
Thanks



On Tue, Dec 18, 2018 at 2:53 PM Oleg Kalnichevski  wrote:

> On Tue, 2018-12-18 at 14:13 +0100, Philippe Mouawad wrote:
> > Hello,
> > We face a bug in JMeter when :
> >
> >- using proxy
> >- and using POST method which leads to a 404
> >- The first request leads as expected to a 404 results
> >- BUT (bug is here) the second one triggers a
> >org.apache.http.NoHttpResponseException: jmeter.apache.org:80
> > failed to
> >respond
> >
> > Bug id:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=63015
> >
> > To reproduce it in Junit below , I just added:
> >
> >- EntityUtils.consumeQuietly(response.getEntity());
> >
> > This call  consumes data and at the end will call
> > ConnHolder#releaseConnection(true).
> > While if missing, ConnHolder#releaseConnection(false) would be called
> > closing the Connection so since we start with a new one, it's ok.
> >
> > In JMeter , since we consume data we end up calling
> > eofWatcher.eofDetected(toCheckStream);which calls
> > ResponseEntityProxy#eofDetected which calls
> > ConnHolder#releaseConnection(true);
> >
> >
> >
> > Find below JUnit:
> >
>
> JUnit passes for me. Squid proxy docker image can be found here:
>
>
> https://github.com/apache/httpcomponents-client/tree/master/httpclient5-testing/docker/squid
>
> Oleg
>
> > @Test
> > public void bugWithPostAndProxy() throws Exception {
> > PoolingHttpClientConnectionManager pHCCM = new
> > PoolingHttpClientConnectionManager(2000, TimeUnit.MILLISECONDS);
> > pHCCM.setDefaultMaxPerRoute(5);
> > pHCCM.setValidateAfterInactivity(1700);
> > HttpHost proxy = new HttpHost("localhost", , "http");
> >
> > RequestConfig config =
> > RequestConfig.custom().setProxy(proxy).build();
> >
> > try (CloseableHttpClient httpclient = HttpClients.custom().
> > setConnectionManager(pHCCM).
> > setDefaultSocketConfig(SocketConfig.DEFAULT).
> > setConnectionTimeToLive(2000, TimeUnit.MILLISECONDS).
> > setRetryHandler(new
> > StandardHttpRequestRetryHandler(0,
> > false)).
> >
> > setConnectionReuseStrategy(DefaultClientConnectionReuseStrategy.INSTA
> > NCE).
> > build()) {
> > HttpHost target = new HttpHost("jmeter.apache.org");
> > HttpPost request = new HttpPost("/404.html");
> > request.addHeader("Content-Type",
> > "application/x-www-form-urlencoded; charset=UTF-8");
> > request.addHeader("Connection", "keep-alive");
> > request.setConfig(config);
> > HttpContext httpContext = new BasicHttpContext();
> > httpContext.setAttribute(HttpClientContext.USER_TOKEN,
> > "Thread
> > Group1-1");
> > try (CloseableHttpResponse response =
> > httpclient.execute(target, request, httpContext)) {
> > logger.info("Headers:{}",
> > response.getEntity().toString());
> > EntityUtils.consumeQuietly(response.getEntity());
> > logger.info("Headers:{}", response.getAllHeaders());
> > }
> > request = new HttpPost("/404.html");
> > request.addHeader("Connection", "keep-alive");
> > try (CloseableHttpResponse response =
> > httpclient.execute(target, request, httpContext)) {
> > EntityUtils.consumeQuietly(response.getEntity());
> > logger.info("Headers:{}",
> > response.getEntity().toString());
> > logger.info("Headers:{}", response.getAllHeaders());
> > }
> > }
> > }
> >
> >
> >
> > Stacktrace:
> > org.apache.http.NoHttpResponseException: jmeter.apache.org:80 failed
> > to
> > respond
> > at
> > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default
> > HttpResponseParser.java:141)
> > at
> > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(Default
> > HttpResponseParser.java:56)
> > at
> > org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePa
> > rser.java:259)
> > at
> > org.apache.http.impl.D

Issue with Proxy / keep alive , getting NoHttpResponseException after a failed request

[Philippe Mouawad]

Hello,
We face a bug in JMeter when :

   - using proxy
   - and using POST method which leads to a 404
   - The first request leads as expected to a 404 results
   - BUT (bug is here) the second one triggers a
   org.apache.http.NoHttpResponseException: jmeter.apache.org:80 failed to
   respond

Bug id:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63015

To reproduce it in Junit below , I just added:

   - EntityUtils.consumeQuietly(response.getEntity());

This call  consumes data and at the end will call
ConnHolder#releaseConnection(true).
While if missing, ConnHolder#releaseConnection(false) would be called
closing the Connection so since we start with a new one, it's ok.

In JMeter , since we consume data we end up calling
eofWatcher.eofDetected(toCheckStream);which calls
ResponseEntityProxy#eofDetected which calls
ConnHolder#releaseConnection(true);



Find below JUnit:

@Test
public void bugWithPostAndProxy() throws Exception {
PoolingHttpClientConnectionManager pHCCM = new
PoolingHttpClientConnectionManager(2000, TimeUnit.MILLISECONDS);
pHCCM.setDefaultMaxPerRoute(5);
pHCCM.setValidateAfterInactivity(1700);
HttpHost proxy = new HttpHost("localhost", , "http");

RequestConfig config =
RequestConfig.custom().setProxy(proxy).build();

try (CloseableHttpClient httpclient = HttpClients.custom().
setConnectionManager(pHCCM).
setDefaultSocketConfig(SocketConfig.DEFAULT).
setConnectionTimeToLive(2000, TimeUnit.MILLISECONDS).
setRetryHandler(new StandardHttpRequestRetryHandler(0,
false)).

setConnectionReuseStrategy(DefaultClientConnectionReuseStrategy.INSTANCE).
build()) {
HttpHost target = new HttpHost("jmeter.apache.org");
HttpPost request = new HttpPost("/404.html");
request.addHeader("Content-Type",
"application/x-www-form-urlencoded; charset=UTF-8");
request.addHeader("Connection", "keep-alive");
request.setConfig(config);
HttpContext httpContext = new BasicHttpContext();
httpContext.setAttribute(HttpClientContext.USER_TOKEN, "Thread
Group1-1");
try (CloseableHttpResponse response =
httpclient.execute(target, request, httpContext)) {
logger.info("Headers:{}", response.getEntity().toString());
EntityUtils.consumeQuietly(response.getEntity());
logger.info("Headers:{}", response.getAllHeaders());
}
request = new HttpPost("/404.html");
request.addHeader("Connection", "keep-alive");
try (CloseableHttpResponse response =
httpclient.execute(target, request, httpContext)) {
EntityUtils.consumeQuietly(response.getEntity());
logger.info("Headers:{}", response.getEntity().toString());
logger.info("Headers:{}", response.getAllHeaders());
}
}
}



Stacktrace:
org.apache.http.NoHttpResponseException: jmeter.apache.org:80 failed to
respond
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72)
at
org.apache.jmeter.protocol.http.proxy.RequestBug.bugWithPostAndProxy(RequestBug.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.stateme

Re: Strange behaviour when using Proxy

[Philippe Mouawad]

Hello,
Thanks .
Done:
https://issues.apache.org/jira/browse/HTTPCLIENT-1956

Regards

On Sat, Dec 15, 2018 at 9:54 PM Oleg Kalnichevski  wrote:

> On Sat, 2018-12-15 at 15:26 +0100, Philippe Mouawad wrote:
> > Hello,
> > I can create a github project but is it worth just for this  ?
> > I have reworked the test case to try to be more clear.
> >
> > Let me reformulate the problem related to this bug report on jmeter:
> >
> >- https://bz.apache.org/bugzilla/show_bug.cgi?id=62852
> >
>
> Please raise a JIRA for this defect.
>
> Oleg
>
> > 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,
> >   - 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,
> >   - User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161)
> >
> > In test case below:
> >
> >- 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 is the target website, but you can use
> > any
> >site you want
> >- X-Sleep is the custom header that is lost for example
> >
> > ---
> > 
> >package org.apache.jmeter.protocol.http.proxy;
> >
> > import java.util.Arrays;
> >
> > import javax.net.ssl.SSLContext;
> >
> > import org.apache.http.HttpHost;
> > import org.apache.http.HttpRequest;
> > import org.apache.http.client.config.RequestConfig;
> > import org.apache.http.client.methods.CloseableHttpResponse;
> > import org.apache.http.client.methods.HttpGet;
> > import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
> > import org.apache.http.conn.ssl.TrustAllStrategy;
> > import org.apache.http.impl.client.CloseableHttpClient;
> > import org.apache.http.impl.client.HttpClients;
> > import org.apache.http.protocol.BasicHttpContext;
> > import org.apache.http.protocol.HttpContext;
> > import org.apache.http.protocol.HttpCoreContext;
> > import org.apache.http.ssl.SSLContextBuilder;
> > import org.apache.http.ssl.TrustStrategy;
> > import org.hamcrest.CoreMatchers;
> > import org.junit.Assert;
> > import org.junit.Test;
> >
> > public class ProxyBug {
> >
> >
> > @Test
> > public void bugWithRequestThroughProxy() throws Exception {
> > TrustStrategy trustStrategy = new TrustAllStrategy();
> > SSLContext sslContext = new
> > SSLContextBuilder().loadTrustMaterial(null, trustStrategy).build();
> > SSLConnectionSocketFactory socketFactory = new
> > SSLConnectionSocketFactory(sslContext);
> > CloseableHttpClient httpclient =
> > HttpClients.custom().setSSLSocketFactory(socketFactory).build();
> > try {
> >
> > HttpHost target = new HttpHost("jmeter.apache.org", 443,
> > "https");
> > HttpHost proxy = new HttpHost("localhost", , "http");
> >
> > RequestConfig config =
> > RequestConfig.custom().setProxy(proxy).build();
> > HttpGet request = new HttpGet("/");
> > request.addHeader("X-sleep", "5");
> > request.setConfig(config);
> >
> > HttpContext localContext = new BasicHttpContext();
> > CloseableHttpResponse response =
> > httpclient.execute(target,
> > request, localContext);
> > final HttpRequest httpRequestFromLocalContext =
> > (HttpRequest)
> > localContext
> > .getAttribute(HttpCoreContext.HTTP_REQUEST);
> > try {
> >
> > Assert.assertThat(httpRequestFromLocalContext.getRequestLine().getMet
> > hod(),
> > CoreMatchers.is("GET"));
> > Asser

Re: Strange behaviour when using Proxy

[Philippe Mouawad]

Hi Oleg,
Is it clear or do you need more details ?

Shall I create a Jira issue ?

Thanks

On Saturday, December 15, 2018, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:

> Hello,
> I can create a github project but is it worth just for this  ?
> I have reworked the test case to try to be more clear.
>
> Let me reformulate the problem related to this bug report on jmeter:
>
>- 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,
>   - 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,
>   - User-Agent: Apache-HttpClient/4.5.6 (Java/1.8.0_161)
>
> In test case below:
>
>- 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 is the target website, but you can use any
>site you want
>- X-Sleep is the custom header that is lost for example
>
> 
> ---
>package org.apache.jmeter.protocol.http.proxy;
>
> import java.util.Arrays;
>
> import javax.net.ssl.SSLContext;
>
> import org.apache.http.HttpHost;
> import org.apache.http.HttpRequest;
> import org.apache.http.client.config.RequestConfig;
> import org.apache.http.client.methods.CloseableHttpResponse;
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
> import org.apache.http.conn.ssl.TrustAllStrategy;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> import org.apache.http.protocol.BasicHttpContext;
> import org.apache.http.protocol.HttpContext;
> import org.apache.http.protocol.HttpCoreContext;
> import org.apache.http.ssl.SSLContextBuilder;
> import org.apache.http.ssl.TrustStrategy;
> import org.hamcrest.CoreMatchers;
> import org.junit.Assert;
> import org.junit.Test;
>
> public class ProxyBug {
>
>
> @Test
> public void bugWithRequestThroughProxy() throws Exception {
> TrustStrategy trustStrategy = new TrustAllStrategy();
> SSLContext sslContext = new 
> SSLContextBuilder().loadTrustMaterial(null,
> trustStrategy).build();
> SSLConnectionSocketFactory socketFactory = new
> SSLConnectionSocketFactory(sslContext);
> CloseableHttpClient httpclient = HttpClients.custom().
> setSSLSocketFactory(socketFactory).build();
> try {
>
> HttpHost target = new HttpHost("jmeter.apache.org", 443,
> "https");
> HttpHost proxy = new HttpHost("localhost", , "http");
>
> RequestConfig config = RequestConfig.custom().
> setProxy(proxy).build();
> HttpGet request = new HttpGet("/");
> request.addHeader("X-sleep", "5");
> request.setConfig(config);
>
> HttpContext localContext = new BasicHttpContext();
> CloseableHttpResponse response = httpclient.execute(target,
> request, localContext);
> final HttpRequest httpRequestFromLocalContext = (HttpRequest)
> localContext
> .getAttribute(HttpCoreContext.HTTP_REQUEST);
> try {
> 
> Assert.assertThat(httpRequestFromLocalContext.getRequestLine().getMethod(),
> CoreMatchers.is("GET"));
> Assert.assertThat(response.getStatusLine().getStatusCode(),
> CoreMatchers.is(200));
> Assert.assertThat(Arrays.asList(request.getAllHeaders()
> ).toString(),
> CoreMatchers.containsString("X-sleep"));
> Assert.assertThat(Arrays.asList(
> httpRequestFromLocalContext.getAllHeaders()).toString(),
> CoreMatchers.containsString("X-sleep"));
>
> } finally {
> response.close();
> }
> } finally {
> httpclient.close();
> }
> }
>
&

Re: Strange behaviour when using Proxy

[Philippe Mouawad]

ext = new BasicHttpContext();
CloseableHttpResponse response = httpclient.execute(target,
request, localContext);
final HttpRequest httpRequestFromLocalContext = (HttpRequest)
localContext
.getAttribute(HttpCoreContext.HTTP_REQUEST);
try {

Assert.assertThat(httpRequestFromLocalContext.getRequestLine().getMethod(),
CoreMatchers.is("GET"));
Assert.assertThat(response.getStatusLine().getStatusCode(),
CoreMatchers.is(200));

Assert.assertThat(Arrays.asList(request.getAllHeaders()).toString(),
CoreMatchers.containsString("X-sleep"));

Assert.assertThat(Arrays.asList(httpRequestFromLocalContext.getAllHeaders()).toString(),
CoreMatchers.containsString("X-sleep"));

} finally {
response.close();
}
} finally {
httpclient.close();
}
}
}

-------

On Sat, Dec 15, 2018 at 3:11 PM Oleg Kalnichevski  wrote:

> On Sat, 2018-12-15 at 15:09 +0100, Philippe Mouawad wrote:
> > Yes, I should have adjusted it.
> > The bug for us is that while we should get the GET method in
> > localContext.getAttribute(HttpCoreContext.HTTP_REQUEST) we end up
> > with the
> > proxy related on which is CONNECT and contains only partial headers.
> >
>
> I am sorry I do not understand what it is exactly you consider to be a
> problem. Could you please create a GitHub project containing the test
> case with the correct asserts that clearly define your expectations?
>
> Oleg
>
>
> > Regards
> >
> > On Sat, Dec 15, 2018 at 2:57 PM Oleg Kalnichevski 
> > wrote:
> >
> > > On Sat, 2018-12-15 at 14:51 +0100, Philippe Mouawad wrote:
> > > > Hello Oleg,
> > > > Felix has created a JUnit test that shows our issue:
> > > >
> > > >- We use localhost: as proxy
> > > >- And https://jmeter.apache.org is the target site
> > > >
> > > > Note that in JMeter we use the HttpRequest from HttpContext as it
> > > > contains
> > > > all the headers :
> > > >
> > > >- [Host: jmeter.apache.org:443, User-Agent: Apache-
> > > > HttpClient/4.5.6
> > > >(Java/1.8.0_161)]
> > > >- It should also contains X-sleep: 5 but as you will see, it
> > > > doesn't
> > > >
> > > >
> > > >
> > > > @Test
> > > > public void checkThatHeadersAreNotHidden() throws Exception {
> > > > TrustStrategy trustStrategy = new TrustAllStrategy();
> > > > SSLContext sslContext = new
> > > > SSLContextBuilder().loadTrustMaterial(null,
> > > > trustStrategy).build();
> > > > SSLConnectionSocketFactory socketFactory = new
> > > > SSLConnectionSocketFactory(sslContext);
> > > > CloseableHttpClient httpclient =
> > > > HttpClients.custom().setSSLSocketFactory(socketFactory).build();
> > > > try {
> > > >
> > > > HttpHost target = new HttpHost("jmeter.apache.org",
> > > > 443,
> > > > "https");
> > > > HttpHost proxy = new HttpHost("localhost", ,
> > > > "http");
> > > >
> > > > RequestConfig config =
> > > > RequestConfig.custom().setProxy(proxy).build();
> > > > HttpGet request = new HttpGet("/");
> > > > request.addHeader("X-sleep", "5");
> > > > request.setConfig(config);
> > > >
> > > > HttpContext localContext = new BasicHttpContext();
> > > > CloseableHttpResponse response =
> > > > httpclient.execute(target,
> > > > request, localContext);
> > > > final HttpRequest httpRequestFromLocalContext =
> > > > (HttpRequest)
> > > > localContext
> > > > .getAttribute(HttpCoreContext.HTTP_REQUEST);
> > > > try {
> > > >
> > > > Assert.assertThat(httpRequestFromLocalContext.getRequestLine().ge
> > > > tMet
> > > > hod(),
> > > > CoreMatchers.is("CONNECT"));
> > >
> > > This assert does not make sense to me. Why would one expect the
> > > method
> > > to be CONNECT when clearly GET is being issued?
> > >
> > > Oleg
>

Re: Strange behaviour when using Proxy

[Philippe Mouawad]

Yes, I should have adjusted it.
The bug for us is that while we should get the GET method in
localContext.getAttribute(HttpCoreContext.HTTP_REQUEST) we end up with the
proxy related on which is CONNECT and contains only partial headers.

Regards

On Sat, Dec 15, 2018 at 2:57 PM Oleg Kalnichevski  wrote:

> On Sat, 2018-12-15 at 14:51 +0100, Philippe Mouawad wrote:
> > Hello Oleg,
> > Felix has created a JUnit test that shows our issue:
> >
> >- We use localhost: as proxy
> >- And https://jmeter.apache.org is the target site
> >
> > Note that in JMeter we use the HttpRequest from HttpContext as it
> > contains
> > all the headers :
> >
> >- [Host: jmeter.apache.org:443, User-Agent: Apache-
> > HttpClient/4.5.6
> >(Java/1.8.0_161)]
> >- It should also contains X-sleep: 5 but as you will see, it
> > doesn't
> >
> >
> >
> > @Test
> > public void checkThatHeadersAreNotHidden() throws Exception {
> > TrustStrategy trustStrategy = new TrustAllStrategy();
> > SSLContext sslContext = new
> > SSLContextBuilder().loadTrustMaterial(null, trustStrategy).build();
> > SSLConnectionSocketFactory socketFactory = new
> > SSLConnectionSocketFactory(sslContext);
> > CloseableHttpClient httpclient =
> > HttpClients.custom().setSSLSocketFactory(socketFactory).build();
> > try {
> >
> > HttpHost target = new HttpHost("jmeter.apache.org", 443,
> > "https");
> > HttpHost proxy = new HttpHost("localhost", , "http");
> >
> > RequestConfig config =
> > RequestConfig.custom().setProxy(proxy).build();
> > HttpGet request = new HttpGet("/");
> > request.addHeader("X-sleep", "5");
> > request.setConfig(config);
> >
> > HttpContext localContext = new BasicHttpContext();
> > CloseableHttpResponse response =
> > httpclient.execute(target,
> > request, localContext);
> > final HttpRequest httpRequestFromLocalContext =
> > (HttpRequest)
> > localContext
> > .getAttribute(HttpCoreContext.HTTP_REQUEST);
> > try {
> >
> > Assert.assertThat(httpRequestFromLocalContext.getRequestLine().getMet
> > hod(),
> > CoreMatchers.is("CONNECT"));
>
> This assert does not make sense to me. Why would one expect the method
> to be CONNECT when clearly GET is being issued?
>
> Oleg
>
>
> > Assert.assertThat(response.getStatusLine().getStatusC
> > ode(),
> > CoreMatchers.is(200));
> >
> > Assert.assertThat(Arrays.asList(request.getAllHeaders()).toString(),
> > CoreMatchers.containsString("X-sleep"));
> >
> > Assert.assertThat(Arrays.asList(httpRequestFromLocalContext.getAllHea
> > ders()).toString(),
> > CoreMatchers.containsString("X-sleep"));
> > } finally {
> > response.close();
> > }
> > } finally {
> > httpclient.close();
> > }
> > }
> >
> > On Sat, Dec 15, 2018 at 2:35 PM Oleg Kalnichevski 
> > wrote:
> >
> > > On Sat, 2018-12-15 at 00:40 +0100, Philippe Mouawad wrote:
> > > > Hello ,
> > > > As a complement if you read the thread.
> > > > It appears TestProxy doesn’t enter in Tunnel_target mode while
> > > > JMeter
> > > > does
> > > > which triggers the issue.
> > > >
> > > > How can I make HttpClient enter this mode using TestProxy code
> > > > (in
> > > > thread)
> > > > below so that I can provide a reproducer for issue?
> > >
> > > You need to make sure the route is marked as TunnelType.TUNNELLED.
> > > Secure `https` routes are marked TunnelType.TUNNELLED by default.
> > >
> > > Oleg
> > >
> > >
> > > > I tried debugging but I don’t understand, it seems it depends on
> > > > number of
> > > > Hop in httpRoute, but javadocs is very succinct.
> > > >
> > > > Thanks
> > > >
> > > > On Friday, December 14, 2018, Philippe Mouawad <
> > > > pmoua...@apache.org>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > > We have a bug report at JMeter where request headers are lost
> > > > > wh

Re: Strange behaviour when using Proxy

[Philippe Mouawad]

Hello Oleg,
Felix has created a JUnit test that shows our issue:

   - We use localhost: as proxy
   - And https://jmeter.apache.org is the target site

Note that in JMeter we use the HttpRequest from HttpContext as it contains
all the headers :

   - [Host: jmeter.apache.org:443, User-Agent: Apache-HttpClient/4.5.6
   (Java/1.8.0_161)]
   - It should also contains X-sleep: 5 but as you will see, it doesn't



@Test
public void checkThatHeadersAreNotHidden() throws Exception {
TrustStrategy trustStrategy = new TrustAllStrategy();
SSLContext sslContext = new
SSLContextBuilder().loadTrustMaterial(null, trustStrategy).build();
SSLConnectionSocketFactory socketFactory = new
SSLConnectionSocketFactory(sslContext);
CloseableHttpClient httpclient =
HttpClients.custom().setSSLSocketFactory(socketFactory).build();
try {

HttpHost target = new HttpHost("jmeter.apache.org", 443,
"https");
HttpHost proxy = new HttpHost("localhost", , "http");

RequestConfig config =
RequestConfig.custom().setProxy(proxy).build();
HttpGet request = new HttpGet("/");
request.addHeader("X-sleep", "5");
request.setConfig(config);

HttpContext localContext = new BasicHttpContext();
CloseableHttpResponse response = httpclient.execute(target,
request, localContext);
final HttpRequest httpRequestFromLocalContext = (HttpRequest)
localContext
.getAttribute(HttpCoreContext.HTTP_REQUEST);
try {

Assert.assertThat(httpRequestFromLocalContext.getRequestLine().getMethod(),
CoreMatchers.is("CONNECT"));
Assert.assertThat(response.getStatusLine().getStatusCode(),
CoreMatchers.is(200));

Assert.assertThat(Arrays.asList(request.getAllHeaders()).toString(),
CoreMatchers.containsString("X-sleep"));

Assert.assertThat(Arrays.asList(httpRequestFromLocalContext.getAllHeaders()).toString(),
CoreMatchers.containsString("X-sleep"));
} finally {
response.close();
}
} finally {
httpclient.close();
}
}

On Sat, Dec 15, 2018 at 2:35 PM Oleg Kalnichevski  wrote:

> On Sat, 2018-12-15 at 00:40 +0100, Philippe Mouawad wrote:
> > Hello ,
> > As a complement if you read the thread.
> > It appears TestProxy doesn’t enter in Tunnel_target mode while JMeter
> > does
> > which triggers the issue.
> >
> > How can I make HttpClient enter this mode using TestProxy code (in
> > thread)
> > below so that I can provide a reproducer for issue?
>
> You need to make sure the route is marked as TunnelType.TUNNELLED.
> Secure `https` routes are marked TunnelType.TUNNELLED by default.
>
> Oleg
>
>
> > I tried debugging but I don’t understand, it seems it depends on
> > number of
> > Hop in httpRoute, but javadocs is very succinct.
> >
> > Thanks
> >
> > On Friday, December 14, 2018, Philippe Mouawad 
> > wrote:
> >
> > > Hello,
> > > We have a bug report at JMeter where request headers are lost when
> > > a proxy
> > > is used for a request.
> > >
> > > You can see thread discussion here:
> > >
> > > http://mail-archives.apache.org/mod_mbox/jmeter-dev/
> > >
> 201812.mbox/%3cf1831746-eeb7-c0df-75e2-565cc2c56...@internetallee.de
> > > %3e
> > >
> > >
> > > It seems hc4 swaps the request stored in local context leading to
> > > the
> > > issue.
> > >
> > >
> > > Regards
> > >
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>

-- 


[image: logo Ubik Ingenierie] <https://www.ubik-ingenierie.com> Philippe
Mouawad
320914981 <+33320914981> | p.moua...@ubik-ingenierie.com
[image: ubik-ingenierie.com] ubik-ingenierie.com
<https://www.ubik-ingenierie.com> | [image: 03.20.91.49.81] 03.20.91.49.81
<+33320914981> | [image: 23 rue du chemin de fer , 59100 , Roubaix] 23 rue
du chemin de fer, 59100, Roubaix
<https://www.openstreetmap.org/#map=18/50.69454/3.16455>

Re: Strange behaviour when using Proxy

[Philippe Mouawad]

Hello ,
As a complement if you read the thread.
It appears TestProxy doesn’t enter in Tunnel_target mode while JMeter does
which triggers the issue.

How can I make HttpClient enter this mode using TestProxy code (in thread)
below so that I can provide a reproducer for issue?
I tried debugging but I don’t understand, it seems it depends on number of
Hop in httpRoute, but javadocs is very succinct.

Thanks

On Friday, December 14, 2018, Philippe Mouawad  wrote:

> Hello,
> We have a bug report at JMeter where request headers are lost when a proxy
> is used for a request.
>
> You can see thread discussion here:
>
> http://mail-archives.apache.org/mod_mbox/jmeter-dev/
> 201812.mbox/%3cf1831746-eeb7-c0df-75e2-565cc2c56...@internetallee.de%3e
>
>
> It seems hc4 swaps the request stored in local context leading to the
> issue.
>
>
> Regards
>

Strange behaviour when using Proxy

[Philippe Mouawad]

Hello,
We have a bug report at JMeter where request headers are lost when a proxy
is used for a request.

You can see thread discussion here:

http://mail-archives.apache.org/mod_mbox/jmeter-dev/201812.mbox/%3cf1831746-eeb7-c0df-75e2-565cc2c56...@internetallee.de%3e


It seems hc4 swaps the request stored in local context leading to the issue.


Regards

Zipping HTTP Request

[Philippe Mouawad]

Hello,
There are sometimes a requirement to automatically gzip the request body
whenever Content-Encoding is set to gzip.

Would you find it interesting to add this feature to HttpClient ?

The implementation would look like:

private static final class GzipHttpRequestInterceptor implements
HttpRequestInterceptor {
@Override
public void process(HttpRequest request, HttpContext context)
throws HttpException, IOException {
if(request instanceof HttpEntityEnclosingRequest) {
Header header = request.getFirstHeader("Content-Encoding");
if(header != null && "gzip".equals(header.getValue())) {
HttpEntityEnclosingRequest enclosingRequest =
(HttpEntityEnclosingRequest) request;
HttpEntity entity = enclosingRequest.getEntity();
ByteArrayOutputStream out = new ByteArrayOutputStream();
try (GZIPOutputStream gzipOS = new
GZIPOutputStream(out)) {
entity.writeTo(gzipOS);
}
enclosingRequest.setEntity(new
ByteArrayEntity(out.toByteArray()));
}
}
}
}


Use could add it to processing like this:

   - builder.addInterceptorFirst(new GzipHttpRequestInterceptor() );

Or it could be enabled by default.


Questions:

   - Would you accept it as a PR ?
   - Do you see immediate improvements in the provided code ?

Thanks
-- 
Regards
Philippe Mouawad.
Ubik-Ingénierie

Re: Correct way of computing Response size

[Philippe Mouawad]

Thanks Oleg for your help !

On Fri, Apr 20, 2018 at 3:41 PM, Oleg Kalnichevski  wrote:

> On Fri, 2018-04-20 at 15:29 +0200, Philippe Mouawad wrote:
> > Is this approximation acceptable ?
> > context.setAttribute(CONTEXT_ATTRIBUTE_RECEIVED_BYTES,
> > metrics.getReceivedBytesCount()+
> > (entity != null ? entity.getContentLength():
> > 0L));
> >
>
> It depends what consider acceptable but this will produce complete
> garbage for chunked messages as their entity content length is always
> -1.
>
> Oleg
>
> > On Fri, Apr 20, 2018 at 3:28 PM, Oleg Kalnichevski 
> > wrote:
> >
> > > On Fri, 2018-04-20 at 15:01 +0200, Philippe Mouawad wrote:
> > > > I am looking for raw content length
> > > >
> > >
> > > This cannot be done reliably with HttpClient 4.x (or I cannot think
> > > of
> > > a way at the moment) as it requires a direct access to the
> > > underlying
> > > connection. It would require dropping to HttpCore level and a
> > > manual
> > > connection management.
> > >
> > > Oleg
> > >
> > >
> > > > On Fri, Apr 20, 2018 at 2:58 PM, Oleg Kalnichevski  > > > org>
> > > > wrote:
> > > >
> > > > > On Fri, 2018-04-20 at 14:31 +0200, Philippe Mouawad wrote:
> > > > > > On Fri, Apr 20, 2018 at 1:01 PM, Oleg Kalnichevski  > > > > > onsu
> > > > > > ltin
> > > > > > g.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Fri, 2018-04-20 at 11:40 +0200, Philippe Mouawad wrote:
> > > > > > > > Hello Oleg,
> > > > > > > > Thanks for rapid answer.
> > > > > > > > The body size including entity.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Should this number represent raw bytes (including the size
> > > > > > > of
> > > > > > > transfer
> > > > > > > encoding elements)
> > > > > >
> > > > > >
> > > > > > Can you illustrate so that I am sure to understand what you
> > > > > > mean
> > > > > > by
> > > > > > size of
> > > > > > transfer
> > > > > > encoding elements ?
> > > > > >
> > > > >
> > > > > ---
> > > > > HTTP/1.1 200 OK\r\n
> > > > > Content-Length: 5\r\n
> > > > > \r\n
> > > > > stuff
> > > > > ---
> > > > >
> > > > > total message length: 43
> > > > > raw content length: 5
> > > > > content length: 5
> > > > >
> > > > > ---
> > > > > HTTP/1.1 200 OK\r\n
> > > > > Transfer-Encoding: chunked\r\n
> > > > > \r\n
> > > > > 5\r\n
> > > > > stuff0\r\n
> > > > > \r\
> > > > > n
> > > > > ---
> > > > >
> > > > > total message length: 60
> > > > > raw content length: 16
> > > > > content length: 5
> > > > >
> > > > > What number are you after?
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > > >
> > > > > > > or content bytes only (same of Content-Length when
> > > > > > > present)?
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > It would be much easier if you took the size of the entire
> > > > > > > message.
> > > > > > >
> > > > > >
> > > > > > How should I proceed ?
> > > > > >
> > > > > > >
> > > > > > > Oleg
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > I'd like the header size to be aside, I already know how
> > > > > > > > to
> > > > > > > > compute
> > > > > > > > header
> > > > > > > > size.
> > > > > > > >
> > > > > > > 

Re: Correct way of computing Response size

[Philippe Mouawad]

Is this approximation acceptable ?
context.setAttribute(CONTEXT_ATTRIBUTE_RECEIVED_BYTES,
metrics.getReceivedBytesCount()+
(entity != null ? entity.getContentLength(): 0L));

On Fri, Apr 20, 2018 at 3:28 PM, Oleg Kalnichevski  wrote:

> On Fri, 2018-04-20 at 15:01 +0200, Philippe Mouawad wrote:
> > I am looking for raw content length
> >
>
> This cannot be done reliably with HttpClient 4.x (or I cannot think of
> a way at the moment) as it requires a direct access to the underlying
> connection. It would require dropping to HttpCore level and a manual
> connection management.
>
> Oleg
>
>
> > On Fri, Apr 20, 2018 at 2:58 PM, Oleg Kalnichevski 
> > wrote:
> >
> > > On Fri, 2018-04-20 at 14:31 +0200, Philippe Mouawad wrote:
> > > > On Fri, Apr 20, 2018 at 1:01 PM, Oleg Kalnichevski  > > > ltin
> > > > g.com>
> > > > wrote:
> > > >
> > > > > On Fri, 2018-04-20 at 11:40 +0200, Philippe Mouawad wrote:
> > > > > > Hello Oleg,
> > > > > > Thanks for rapid answer.
> > > > > > The body size including entity.
> > > > > >
> > > > >
> > > > >
> > > > > Should this number represent raw bytes (including the size of
> > > > > transfer
> > > > > encoding elements)
> > > >
> > > >
> > > > Can you illustrate so that I am sure to understand what you mean
> > > > by
> > > > size of
> > > > transfer
> > > > encoding elements ?
> > > >
> > >
> > > ---
> > > HTTP/1.1 200 OK\r\n
> > > Content-Length: 5\r\n
> > > \r\n
> > > stuff
> > > ---
> > >
> > > total message length: 43
> > > raw content length: 5
> > > content length: 5
> > >
> > > ---
> > > HTTP/1.1 200 OK\r\n
> > > Transfer-Encoding: chunked\r\n
> > > \r\n
> > > 5\r\n
> > > stuff0\r\n
> > > \r\
> > > n
> > > ---
> > >
> > > total message length: 60
> > > raw content length: 16
> > > content length: 5
> > >
> > > What number are you after?
> > >
> > > Oleg
> > >
> > >
> > > >
> > > > > or content bytes only (same of Content-Length when
> > > > > present)?
> > > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > It would be much easier if you took the size of the entire
> > > > > message.
> > > > >
> > > >
> > > > How should I proceed ?
> > > >
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > >
> > > > > > I'd like the header size to be aside, I already know how to
> > > > > > compute
> > > > > > header
> > > > > > size.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 20, 2018 at 11:21 AM, Oleg Kalnichevski  > > > > > ache
> > > > > > .org
> > > > > > >
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Fri, 2018-04-20 at 11:09 +0200, Philippe Mouawad wrote:
> > > > > > > > Hello ,
> > > > > > > >
> > > > > > > > In current Live version of JMeter we use this way of
> > > > > > > > computing
> > > > > > > > size
> > > > > > > > of
> > > > > > > > responses for each request:
> > > > > > > >
> > > > > > > >-
> > > > > > > >https://github.com/apache/jmeter/blob/v4_0/src/protoco
> > > > > > > > l/ht
> > > > > > > > tp/o
> > > > > > > > rg/a
> > > > > > > > pache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L888
> > > > > > > >
> > > > > > > >
> > > > > > > > As we migrated to last APIs we based implementation on
> > > > > > > > this
> > > > > > > > SO
> > > > > > > > response
> > > >

Re: Correct way of computing Response size

[Philippe Mouawad]

I am looking for raw content length

On Fri, Apr 20, 2018 at 2:58 PM, Oleg Kalnichevski  wrote:

> On Fri, 2018-04-20 at 14:31 +0200, Philippe Mouawad wrote:
> > On Fri, Apr 20, 2018 at 1:01 PM, Oleg Kalnichevski  > g.com>
> > wrote:
> >
> > > On Fri, 2018-04-20 at 11:40 +0200, Philippe Mouawad wrote:
> > > > Hello Oleg,
> > > > Thanks for rapid answer.
> > > > The body size including entity.
> > > >
> > >
> > >
> > > Should this number represent raw bytes (including the size of
> > > transfer
> > > encoding elements)
> >
> >
> > Can you illustrate so that I am sure to understand what you mean by
> > size of
> > transfer
> > encoding elements ?
> >
>
> ---
> HTTP/1.1 200 OK\r\n
> Content-Length: 5\r\n
> \r\n
> stuff
> ---
>
> total message length: 43
> raw content length: 5
> content length: 5
>
> ---
> HTTP/1.1 200 OK\r\n
> Transfer-Encoding: chunked\r\n
> \r\n
> 5\r\n
> stuff0\r\n
> \r\
> n
> ---
>
> total message length: 60
> raw content length: 16
> content length: 5
>
> What number are you after?
>
> Oleg
>
>
> >
> > > or content bytes only (same of Content-Length when
> > > present)?
> > >
> >
> >
> >
> > >
> > > It would be much easier if you took the size of the entire message.
> > >
> >
> > How should I proceed ?
> >
> > >
> > > Oleg
> > >
> > >
> > >
> > > > I'd like the header size to be aside, I already know how to
> > > > compute
> > > > header
> > > > size.
> > > >
> > > > Regards
> > > >
> > > >
> > > > On Fri, Apr 20, 2018 at 11:21 AM, Oleg Kalnichevski  > > > .org
> > > > >
> > > >
> > > > wrote:
> > > >
> > > > > On Fri, 2018-04-20 at 11:09 +0200, Philippe Mouawad wrote:
> > > > > > Hello ,
> > > > > >
> > > > > > In current Live version of JMeter we use this way of
> > > > > > computing
> > > > > > size
> > > > > > of
> > > > > > responses for each request:
> > > > > >
> > > > > >-
> > > > > >https://github.com/apache/jmeter/blob/v4_0/src/protocol/ht
> > > > > > tp/o
> > > > > > rg/a
> > > > > > pache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L888
> > > > > >
> > > > > >
> > > > > > As we migrated to last APIs we based implementation on this
> > > > > > SO
> > > > > > response
> > > > > > from Oleg:
> > > > > >
> > > > > >-
> > > > > >https://stackoverflow.com/questions/26166469/measure-bandw
> > > > > > idth
> > > > > > -usa
> > > > > > ge-with-apache-httpcomponents-httpclient
> > > > > >
> > > > > > And ended up with this:
> > > > > >
> > > > > >-
> > > > > >https://github.com/apache/jmeter/blob/trunk/src/protocol/h
> > > > > > ttp/
> > > > > > org/
> > > > > > apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L382
> > > > > >
> > > > > > But it appears that computation is wrong and we would need to
> > > > > > do
> > > > > > this
> > > > > > to be
> > > > > > correct:
> > > > > >
> > > > > > protected HttpResponse doReceiveResponse(
> > > > > > final HttpRequest request,
> > > > > > final HttpClientConnection conn,
> > > > > > final HttpContext context) throws
> > > > > > HttpException,
> > > > > > IOException {
> > > > > > HttpResponse response =
> > > > > > super.doReceiveResponse(request,
> > > > > > conn,
> > > > > > context);
> > > > > > HttpConnectionMetrics metrics =
> > > > > > conn.getMetrics();
> > > > > > HttpEntity entity = response.getEntity();
> > > > > > context.setAttribute(CONTEXT_ATTRIBUTE_RECEIVED_

Re: Correct way of computing Response size

[Philippe Mouawad]

On Fri, Apr 20, 2018 at 1:01 PM, Oleg Kalnichevski 
wrote:

> On Fri, 2018-04-20 at 11:40 +0200, Philippe Mouawad wrote:
> > Hello Oleg,
> > Thanks for rapid answer.
> > The body size including entity.
> >
>
>
> Should this number represent raw bytes (including the size of transfer
> encoding elements)


Can you illustrate so that I am sure to understand what you mean by size of
transfer
encoding elements ?


> or content bytes only (same of Content-Length when
> present)?
>



>
> It would be much easier if you took the size of the entire message.
>

How should I proceed ?

>
> Oleg
>
>
>
> > I'd like the header size to be aside, I already know how to compute
> > header
> > size.
> >
> > Regards
> >
> >
> > On Fri, Apr 20, 2018 at 11:21 AM, Oleg Kalnichevski  > >
> > wrote:
> >
> > > On Fri, 2018-04-20 at 11:09 +0200, Philippe Mouawad wrote:
> > > > Hello ,
> > > >
> > > > In current Live version of JMeter we use this way of computing
> > > > size
> > > > of
> > > > responses for each request:
> > > >
> > > >-
> > > >https://github.com/apache/jmeter/blob/v4_0/src/protocol/http/o
> > > > rg/a
> > > > pache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L888
> > > >
> > > >
> > > > As we migrated to last APIs we based implementation on this SO
> > > > response
> > > > from Oleg:
> > > >
> > > >-
> > > >https://stackoverflow.com/questions/26166469/measure-bandwidth
> > > > -usa
> > > > ge-with-apache-httpcomponents-httpclient
> > > >
> > > > And ended up with this:
> > > >
> > > >-
> > > >https://github.com/apache/jmeter/blob/trunk/src/protocol/http/
> > > > org/
> > > > apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L382
> > > >
> > > > But it appears that computation is wrong and we would need to do
> > > > this
> > > > to be
> > > > correct:
> > > >
> > > > protected HttpResponse doReceiveResponse(
> > > > final HttpRequest request,
> > > > final HttpClientConnection conn,
> > > > final HttpContext context) throws HttpException,
> > > > IOException {
> > > > HttpResponse response =
> > > > super.doReceiveResponse(request,
> > > > conn,
> > > > context);
> > > > HttpConnectionMetrics metrics = conn.getMetrics();
> > > > HttpEntity entity = response.getEntity();
> > > > context.setAttribute(CONTEXT_ATTRIBUTE_RECEIVED_BYTES
> > > > ,
> > > > metrics.getReceivedBytesCount()+
> > > > (entity != null ? entity.getContentLength():
> > > > 0L));
> > > > metrics.reset();
> > > > return response;
> > > > }
> > > >
> > >
> > > Philippe
> > >
> > > Are you trying to calculate the size of an entire response (message
> > > head + message entity body) or a response entity only?
> > >
> > > Oleg
> > >
> > > >
> > > > Is my understanding correct ? or am I missing something ?
> > > >
> > > > Thanks
> > > >
> > > > Regards
> > >
> > > -
> > > 
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.or
> > > g
> > >
> > >
> >
> >
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: Correct way of computing Response size

[Philippe Mouawad]

Hello Oleg,
Thanks for rapid answer.
The body size including entity.

I'd like the header size to be aside, I already know how to compute header
size.

Regards


On Fri, Apr 20, 2018 at 11:21 AM, Oleg Kalnichevski 
wrote:

> On Fri, 2018-04-20 at 11:09 +0200, Philippe Mouawad wrote:
> > Hello ,
> >
> > In current Live version of JMeter we use this way of computing size
> > of
> > responses for each request:
> >
> >-
> >https://github.com/apache/jmeter/blob/v4_0/src/protocol/http/org/a
> > pache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L888
> >
> >
> > As we migrated to last APIs we based implementation on this SO
> > response
> > from Oleg:
> >
> >-
> >https://stackoverflow.com/questions/26166469/measure-bandwidth-usa
> > ge-with-apache-httpcomponents-httpclient
> >
> > And ended up with this:
> >
> >-
> >https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/
> > apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L382
> >
> > But it appears that computation is wrong and we would need to do this
> > to be
> > correct:
> >
> > protected HttpResponse doReceiveResponse(
> > final HttpRequest request,
> > final HttpClientConnection conn,
> > final HttpContext context) throws HttpException,
> > IOException {
> > HttpResponse response = super.doReceiveResponse(request,
> > conn,
> > context);
> > HttpConnectionMetrics metrics = conn.getMetrics();
> > HttpEntity entity = response.getEntity();
> > context.setAttribute(CONTEXT_ATTRIBUTE_RECEIVED_BYTES,
> > metrics.getReceivedBytesCount()+
> > (entity != null ? entity.getContentLength():
> > 0L));
> > metrics.reset();
> > return response;
> > }
> >
>
> Philippe
>
> Are you trying to calculate the size of an entire response (message
> head + message entity body) or a response entity only?
>
> Oleg
>
> >
> > Is my understanding correct ? or am I missing something ?
> >
> > Thanks
> >
> > Regards
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Correct way of computing Response size

[Philippe Mouawad]

Hello ,

In current Live version of JMeter we use this way of computing size of
responses for each request:

   -
   
https://github.com/apache/jmeter/blob/v4_0/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L888


As we migrated to last APIs we based implementation on this SO response
from Oleg:

   -
   
https://stackoverflow.com/questions/26166469/measure-bandwidth-usage-with-apache-httpcomponents-httpclient

And ended up with this:

   -
   
https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L382

But it appears that computation is wrong and we would need to do this to be
correct:

protected HttpResponse doReceiveResponse(
final HttpRequest request,
final HttpClientConnection conn,
final HttpContext context) throws HttpException,
IOException {
HttpResponse response = super.doReceiveResponse(request, conn,
context);
HttpConnectionMetrics metrics = conn.getMetrics();
HttpEntity entity = response.getEntity();
context.setAttribute(CONTEXT_ATTRIBUTE_RECEIVED_BYTES,
metrics.getReceivedBytesCount()+
(entity != null ? entity.getContentLength(): 0L));
metrics.reset();
return response;
}


Is my understanding correct ? or am I missing something ?

Thanks

Regards

Website not up to date for HC5

[Philippe Mouawad]

Hello,
When you go to:


   - https://hc.apache.org/httpcomponents-client-5.0.x/index.html


It doesn't mention support of HTTP2 which is a bit sad knowing all the
important work done to support it.

Regards
Philippe

Re: How to clear SSL State in HC4.5.5

[Philippe Mouawad]

It looks a bit aggressive to me, but if you say it’s ok, it’s fine for me.

So you confirm I need to keep reference to
poolingHttpClientConnectionManager right ?
No way from httpclient

Thanks
On Sunday, March 11, 2018, Oleg Kalnichevski  wrote:

> On Sun, 2018-03-11 at 15:57 +0100, Philippe Mouawad wrote:
> > I mean starting with a fresh sslcontext.
> > It works if I keep a ref on PoolingHttpConnectionManager and call
> >
> > poolingHttppoolingHttpClientConnectionManagerClientConnectionMan
> ager.closeExpiredConnections();

> poolingHttpClientConnectionManager.closeIdleConnections(1L,
> > TimeUnit.MICROSECONDS);
> >
> >
> > But is there a better way ?
>
> What is so bad about using the connection manager to close out all
> persistent connections?
>
> Oleg
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: How to clear SSL State in HC4.5.5

[Philippe Mouawad]

I mean starting with a fresh sslcontext.
It works if I keep a ref on PoolingHttpConnectionManager and call

poolingHttpClientConnectionManager.closeExpiredConnections();
poolingHttpClientConnectionManager.closeIdleConnections(1L,
TimeUnit.MICROSECONDS);


But is there a better way ?
Thanks

Regards
On Sunday, March 11, 2018, Oleg Kalnichevski  wrote:

> On Sat, 2018-03-10 at 14:08 +0100, Philippe Mouawad wrote:
> > ...
>
> > > Hello,
> > >
> > > In current jmeter trunk when we have Client certificate
> > > authentication and
> > > we need to reset SSL State so another SSLContext is created we do
> > > this:
> > > https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/a
> > > pache/
> > > jmeter/protocol/http/sampler/HTTPHC4Impl.java#L838
> > >
> > >
> > > We are currently migrating to last 4.5 and would like to know what
> > > is the
> > > clean way to reset SSL State ?
>
> I am not sure I understand what exactly you mean by resetting SSL
> state.
>
> Oleg
>
>
> > > Since httpClient.getConnectionManager() is deprecated.
> > > Should we keep a reference to PoolingHttpClientConnectionManager
> > > and call
> > > those methods on it ?
> > >
> > > Current state of migration is here:
> > >
> > >- https://github.com/ubikloadpack/jmeter/blob/HC4_
> > >FULL_MIGRATION/src/protocol/http/org/apache/jmeter/
> > >protocol/http/sampler/HTTPHC4Impl.java#L973
> > ><https://github.com/ubikloadpack/jmeter/blob/HC4_FULL_MIGRATION/
> > > src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Im
> > > pl.java#L973>
> > >
> > >
> > > To recap, in JMeter we have 1 HttpClient per User (and this is
> > > needed as
> > > per a previous discussion on this mailing list).
> > >
> > > Thanks for your help.
> > > --
> > > Regards.
> > > Philippe M.
> > >
> > >
> > >
> >
> >
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: How to clear SSL State in HC4.5.5

[Philippe Mouawad]

Hello,
Any feedback on this ?


Thanks

On Sat, Feb 24, 2018 at 12:24 PM, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:

> Hello,
>
> In current jmeter trunk when we have Client certificate authentication and
> we need to reset SSL State so another SSLContext is created we do this:
> https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/
> jmeter/protocol/http/sampler/HTTPHC4Impl.java#L838
>
>
> We are currently migrating to last 4.5 and would like to know what is the
> clean way to reset SSL State ?
> Since httpClient.getConnectionManager() is deprecated.
> Should we keep a reference to PoolingHttpClientConnectionManager and call
> those methods on it ?
>
> Current state of migration is here:
>
>- https://github.com/ubikloadpack/jmeter/blob/HC4_
>FULL_MIGRATION/src/protocol/http/org/apache/jmeter/
>protocol/http/sampler/HTTPHC4Impl.java#L973
>
> <https://github.com/ubikloadpack/jmeter/blob/HC4_FULL_MIGRATION/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L973>
>
>
> To recap, in JMeter we have 1 HttpClient per User (and this is needed as
> per a previous discussion on this mailing list).
>
> Thanks for your help.
> --
> Regards.
> Philippe M.
>
>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

How to clear SSL State in HC4.5.5

[Philippe Mouawad]

Hello,

In current jmeter trunk when we have Client certificate authentication and
we need to reset SSL State so another SSLContext is created we do this:
https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L838


We are currently migrating to last 4.5 and would like to know what is the
clean way to reset SSL State ?
Since httpClient.getConnectionManager() is deprecated.
Should we keep a reference to PoolingHttpClientConnectionManager and call
those methods on it ?

Current state of migration is here:

   -
   
https://github.com/ubikloadpack/jmeter/blob/HC4_FULL_MIGRATION/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L973


To recap, in JMeter we have 1 HttpClient per User (and this is needed as
per a previous discussion on this mailing list).

Thanks for your help.
-- 
Regards.
Philippe M.

Re: Are there any "Upgrading from 4.x" notes for the alpha/beta 5.0 releases? (trying to update Solr)

[Philippe Mouawad]

Hello,
I support such idea although I am aware the HC Team is not very big and
would need volunteers.

As an example, I must say that for example migrating from 4.2 to 4.5.X was
not very easy and lacked documentation.
Hopefully, it is in progress at JMeter project but having one for 4.5 =>
5.X would be great.

Thanks in advance.
Regards

On Wed, Dec 13, 2017 at 11:29 PM, Shawn Heisey  wrote:

> I'm trying to prepare Solr for the release of the 5.0 versions of
> httpcomponents.  When I update the ivy config to pull down the
> alpha/beta 5.0 releases, there are naturally a lot of errors in the code.
>
> The "Organize Imports" function in eclipse can find many of the classes
> whose packages have changed, but I am also finding it difficult to
> locate replacement classes for things that seem to have simply
> disappeared.  One example is org.apache.http.message.AbstractHttpMessage.
>
> Is there anyplace I can go to find documentation that can help me figure
> out how to alter an existing project for the new version?
>
> Side note:  It is likely that Solr is using paradigms and methods that
> have been discouraged by this project for a long time.  Is there an IRC
> channel for this project where I can have a more realtime discussion
> with an expert?  I can open an issue in Jira on the SOLR project, but
> I'm hoping for something a little less formal for the bulk of the
> discussion.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: Migration to HC4/HC5 last version

[Philippe Mouawad]

No problem Oleg, answering after 2 days is pretty acceptable and you're
doing this on your personal time so I have nothing to say.

I hope you'll handle your personal and work issues and be in a better state
, good luck

On Thu, Oct 12, 2017 at 10:50 AM, Oleg Kalnichevski 
wrote:

> On Wed, 2017-10-11 at 20:55 +0200, Philippe Mouawad wrote:
> > Hello Team,
> > Pinging again in case somebody can help.
> > Regards
> >
>
> My apologies, Philippe
>
> I was (still am) buried under with work related and personal issues.
>
> Oleg
>
>
> >
> > On Mon, Oct 9, 2017 at 11:19 PM, Philippe Mouawad  > g>
> > wrote:
> >
> > > Hello,
> > > Within JMeter projet I am working on migration fully to last APIs
> > > of
> > > HttpClient:
> > >
> > >- https://bz.apache.org/bugzilla/show_bug.cgi?id=58757
> > >
> > > You can see current code here:
> > >
> > >- https://github.com/ubikloadpack/jmeter/tree/HC4_FULL_MIGRATION
> > >
> > > I have nearly completed the work except for 2 remaining items:
> > >
> > >- Virtual Host:
> > >   - I don't see this parameter in newer interfaces
> > >  - https://github.com/apache/jmeter/blob/trunk/src/
> > >  protocol/http/org/apache/jmeter/protocol/http/sampler/
> > >  HTTPHC4Impl.java#L1117
> > >  <https://github.com/apache/jmeter/blob/trunk/src/protocol/
> > > http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L1117
> > > >
> > >
> > >
> > >- "Slow " connection feature:
> > >   - This feature allows to simulate slow connection. Currently
> > > we
> > >   wrap Input/Output stream returned by socket with
> > > SlowInputStream/
> > >   SlowOutputStream
> > >   - https://github.com/apache/jmeter/blob/trunk/src/
> > >  protocol/http/org/apache/jmeter/protocol/http/util/
> > >  SlowHC4SocketFactory.java
> > >  <https://github.com/apache/jmeter/blob/trunk/src/protocol/
> > > http/org/apache/jmeter/protocol/http/util/SlowHC4SocketFactory.java
> > > >
> > >  - https://github.com/apache/jmeter/blob/trunk/src/
> > >  protocol/http/org/apache/jmeter/protocol/http/sampler/
> > >  HTTPHC4Impl.java#L322
> > >  <https://github.com/apache/jmeter/blob/trunk/src/protocol/
> > > http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L322>
> > >  - https://github.com/apache/jmeter/blob/trunk/src/
> > >  protocol/http/org/apache/jmeter/protocol/http/sampler/
> > >  HTTPHC4Impl.java#L892
> > >  <https://github.com/apache/jmeter/blob/trunk/src/protocol/
> > > http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L892>
> > >   - It is not clear for me how this feature should be
> > > implemented:
> > >  - Should we adapt SSLSocket and Socket with a Slow feature
> > > ?
> > >
> > >
> > > Hope you can help by pointing me to the components.
> > >
> > > Thanks
> > >
> > > Regards
> > >
> > > Philippe M.
> > >
> > > @philmdot
> > >
>



-- 
Cordialement.
Philippe Mouawad.

Re: Migration to HC4/HC5 last version

[Philippe Mouawad]

Thanks for your help Aleksei
So 1 question remains for me:

   - "Slow " connection feature:
  - This feature allows to simulate slow connection. Currently we wrap
  Input/Output stream returned by socket with SlowInputStream/
  SlowOutputStream
  - https://github.com/apache/jmeter/blob/trunk/src/
 protocol/http/org/apache/jmeter/protocol/http/util/
 SlowHC4SocketFactory.java
 
<https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/util/SlowHC4SocketFactory.java>
 - https://github.com/apache/jmeter/blob/trunk/src/
 protocol/http/org/apache/jmeter/protocol/http/sampler/
 HTTPHC4Impl.java#L322
 
<https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L322>
 - https://github.com/apache/jmeter/blob/trunk/src/
 protocol/http/org/apache/jmeter/protocol/http/sampler/
 HTTPHC4Impl.java#L892
 
<https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L892>
  - It is not clear for me how this feature should be implemented:
 - Should we adapt SSLSocket and Socket with a Slow feature ?


Regards

On Thu, Oct 12, 2017 at 9:41 AM, Aleksei Balan 
wrote:

> Hello Philippe Mouawad,
>
> I think the idea of getting rid of virtual host is to simplify the
> object design.
> Virtual host functionality can be reduced to simple setting of the
> "Host" header in http request.
> You can see the example of virtual host implementation for httpclient 5.0
> here
> https://github.com/abalanonline/httpclient4to5
>
> Aleksei Balan
>
>
>
> On 10/11/17, Philippe Mouawad  wrote:
> > Hello Team,
> > Pinging again in case somebody can help.
> > Regards
> >
> >
> > On Mon, Oct 9, 2017 at 11:19 PM, Philippe Mouawad 
> > wrote:
> >
> >> Hello,
> >> Within JMeter projet I am working on migration fully to last APIs of
> >> HttpClient:
> >>
> >>- https://bz.apache.org/bugzilla/show_bug.cgi?id=58757
> >>
> >> You can see current code here:
> >>
> >>- https://github.com/ubikloadpack/jmeter/tree/HC4_FULL_MIGRATION
> >>
> >> I have nearly completed the work except for 2 remaining items:
> >>
> >>- Virtual Host:
> >>   - I don't see this parameter in newer interfaces
> >>  - https://github.com/apache/jmeter/blob/trunk/src/
> >>  protocol/http/org/apache/jmeter/protocol/http/sampler/
> >>  HTTPHC4Impl.java#L1117
> >>
> >> <https://github.com/apache/jmeter/blob/trunk/src/
> protocol/http/org/apache/jmeter/protocol/http/sampler/
> HTTPHC4Impl.java#L1117>
> >>
> >>
> >>- "Slow " connection feature:
> >>   - This feature allows to simulate slow connection. Currently we
> >>   wrap Input/Output stream returned by socket with SlowInputStream/
> >>   SlowOutputStream
> >>   - https://github.com/apache/jmeter/blob/trunk/src/
> >>  protocol/http/org/apache/jmeter/protocol/http/util/
> >>  SlowHC4SocketFactory.java
> >>
> >> <https://github.com/apache/jmeter/blob/trunk/src/
> protocol/http/org/apache/jmeter/protocol/http/util/
> SlowHC4SocketFactory.java>
> >>  - https://github.com/apache/jmeter/blob/trunk/src/
> >>  protocol/http/org/apache/jmeter/protocol/http/sampler/
> >>  HTTPHC4Impl.java#L322
> >>
> >> <https://github.com/apache/jmeter/blob/trunk/src/
> protocol/http/org/apache/jmeter/protocol/http/sampler/
> HTTPHC4Impl.java#L322>
> >>  - https://github.com/apache/jmeter/blob/trunk/src/
> >>  protocol/http/org/apache/jmeter/protocol/http/sampler/
> >>  HTTPHC4Impl.java#L892
> >>
> >> <https://github.com/apache/jmeter/blob/trunk/src/
> protocol/http/org/apache/jmeter/protocol/http/sampler/
> HTTPHC4Impl.java#L892>
> >>   - It is not clear for me how this feature should be implemented:
> >>  - Should we adapt SSLSocket and Socket with a Slow feature ?
> >>
> >>
> >> Hope you can help by pointing me to the components.
> >>
> >> Thanks
> >>
> >> Regards
> >>
> >> Philippe M.
> >>
> >> @philmdot
> >>
> >
>



-- 
Cordialement.
Philippe Mouawad.

JMeter Maven Plugin 2.4.0 released

[Philippe Mouawad]

Hello,
3rd party JMeter Maven Plugin 2.4.0 has been released today.

You can read release notes:

   - https://github.com/jmeter-maven-plugin/jmeter-maven-plugin
   - https://github.com/jmeter-maven-plugin/jmeter-maven-
   plugin/blob/master/CHANGELOG.md
   
<https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/blob/master/CHANGELOG.md>


Please note this project is a 3rd party project and not related with ASF.

-- 
Regards.
Philippe Mouawad.
Ubik-Ingénierie

Re: JMeter Maven Plugin 2.4.0 released

[Philippe Mouawad]

Sorry , wrong list.

On Wed, Oct 11, 2017 at 9:27 PM, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:

> Hello,
> 3rd party JMeter Maven Plugin 2.4.0 has been released today.
>
> You can read release notes:
>
>- https://github.com/jmeter-maven-plugin/jmeter-maven-plugin
>- https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/
>blob/master/CHANGELOG.md
>
>
> Please note this project is a 3rd party project and not related with ASF.
>
> --
> Regards.
> Philippe Mouawad.
> Ubik-Ingénierie
>



-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: Migration to HC4/HC5 last version

[Philippe Mouawad]

Hello Team,
Pinging again in case somebody can help.
Regards


On Mon, Oct 9, 2017 at 11:19 PM, Philippe Mouawad 
wrote:

> Hello,
> Within JMeter projet I am working on migration fully to last APIs of
> HttpClient:
>
>- https://bz.apache.org/bugzilla/show_bug.cgi?id=58757
>
> You can see current code here:
>
>- https://github.com/ubikloadpack/jmeter/tree/HC4_FULL_MIGRATION
>
> I have nearly completed the work except for 2 remaining items:
>
>- Virtual Host:
>   - I don't see this parameter in newer interfaces
>  - https://github.com/apache/jmeter/blob/trunk/src/
>  protocol/http/org/apache/jmeter/protocol/http/sampler/
>  HTTPHC4Impl.java#L1117
>  
> <https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L1117>
>
>
>- "Slow " connection feature:
>   - This feature allows to simulate slow connection. Currently we
>   wrap Input/Output stream returned by socket with SlowInputStream/
>   SlowOutputStream
>   - https://github.com/apache/jmeter/blob/trunk/src/
>  protocol/http/org/apache/jmeter/protocol/http/util/
>  SlowHC4SocketFactory.java
>  
> <https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/util/SlowHC4SocketFactory.java>
>  - https://github.com/apache/jmeter/blob/trunk/src/
>  protocol/http/org/apache/jmeter/protocol/http/sampler/
>  HTTPHC4Impl.java#L322
>  
> <https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L322>
>  - https://github.com/apache/jmeter/blob/trunk/src/
>  protocol/http/org/apache/jmeter/protocol/http/sampler/
>  HTTPHC4Impl.java#L892
>  
> <https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L892>
>   - It is not clear for me how this feature should be implemented:
>  - Should we adapt SSLSocket and Socket with a Slow feature ?
>
>
> Hope you can help by pointing me to the components.
>
> Thanks
>
> Regards
>
> Philippe M.
>
> @philmdot
>

Migration to HC4/HC5 last version

[Philippe Mouawad]

Hello,
Within JMeter projet I am working on migration fully to last APIs of
HttpClient:

   - https://bz.apache.org/bugzilla/show_bug.cgi?id=58757

You can see current code here:

   - https://github.com/ubikloadpack/jmeter/tree/HC4_FULL_MIGRATION

I have nearly completed the work except for 2 remaining items:

   - Virtual Host:
  - I don't see this parameter in newer interfaces
 -
 
https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L1117


   - "Slow " connection feature:
  - This feature allows to simulate slow connection. Currently we wrap
  Input/Output stream returned by socket with
SlowInputStream/SlowOutputStream
  -
 
https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/util/SlowHC4SocketFactory.java
 -
 
https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L322
 -
 
https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L892
  - It is not clear for me how this feature should be implemented:
 - Should we adapt SSLSocket and Socket with a Slow feature ?


Hope you can help by pointing me to the components.

Thanks

Regards

Philippe M.

@philmdot

Re: Charset restriction on parameter names

[Philippe Mouawad]

Thanks Oleg.

Did you see my mail sent just before your reply ?

Thanks

On Sunday, August 27, 2017, Oleg Kalnichevski  wrote:

> On Sun, 2017-08-27 at 22:03 +0200, Philippe Mouawad wrote:
> > Hello,
> > I have a question regarding HTTP 1.1 and 2.0 and Multipart encoded
> > form as
> > I didn't find a clear answer in RFC https://tools.ietf.org/html/rfc75
> > 78
> >
> > Is there a restriction on the charset of parameter names, in this
> > case what
> > is the encoding ?
> >
> > Example, can a parameter be named :
> >
> >- 安_param
> >
> >
> > Thanks.
>
> Hi Philippe
>
> As far as I can tell non-ASCII characters in parameter names are not
> permitted based on RFC 2822, section 2.2
>
> ---
> 2.2. Header Fields
>
>Header fields are lines composed of a field name, followed by a colon
>(":"), followed by a field body, and terminated by CRLF.  A field
>name MUST be composed of printable US-ASCII characters (i.e.,
>characters that have values between 33 and 126, inclusive),
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: HTTPCORE-4.4.7 release

[Philippe Mouawad]

Thanks Oleg !

On Sunday, August 27, 2017, Oleg Kalnichevski  wrote:

> On Sun, 2017-08-27 at 22:50 +0200, Philippe Mouawad wrote:
> > Hello,
> > I know you're busy on HTTP/ 2 work for now.
> > But is there a planned release of HTTPCORE 4.4.7 soon :
> >
> >- https://issues.apache.org/jira/projects/HTTPCORE/versions/123391
> > 85
> >
> >
> >
> > Thanks
> >
>
> Philippe,
>
> I am in the process of preparing HttpCore 5.0a4 right now. HttpCore
> 4.4.7 GA should be next in the release pipeline.
>
> Oleg
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

HTTPCORE-4.4.7 release

[Philippe Mouawad]

Hello,
I know you're busy on HTTP/ 2 work for now.
But is there a planned release of HTTPCORE 4.4.7 soon :

   - https://issues.apache.org/jira/projects/HTTPCORE/versions/12339185



Thanks

-- 
Cordialement.
Philippe Mouawad.

Re: Charset restriction on parameter names

[Philippe Mouawad]

It looks like there is such restriction if my understanding is correct:

   -
   
https://stackoverflow.com/questions/20591599/why-arent-post-names-with-unicode-sent-correctly-when-using-multipart-form-data/20592910#20592910


And HTML5 has introduced another way of encoding such parameter names:

   -
   https://www.w3.org/TR/2013/WD-html51-20130528/forms.html#multipart-form-data


Is my understanding correct ?

Thanks for help
Regards


On Sun, Aug 27, 2017 at 10:03 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> I have a question regarding HTTP 1.1 and 2.0 and Multipart encoded form as
> I didn't find a clear answer in RFC https://tools.ietf.org/html/rfc7578
>
> Is there a restriction on the charset of parameter names, in this case
> what is the encoding ?
>
> Example, can a parameter be named :
>
>- 安_param
>
>
> Thanks.
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Charset restriction on parameter names

[Philippe Mouawad]

Hello,
I have a question regarding HTTP 1.1 and 2.0 and Multipart encoded form as
I didn't find a clear answer in RFC https://tools.ietf.org/html/rfc7578

Is there a restriction on the charset of parameter names, in this case what
is the encoding ?

Example, can a parameter be named :

   - 安_param


Thanks.
-- 
Cordialement.
Philippe Mouawad.

Re: MultipartEntityBuilder and Charset US-ASCII

[Philippe Mouawad]

Hello,
Any answers on those questions ?

Thank you

On Sun, May 28, 2017 at 12:47 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hi Oleg,
> From the 3 questions I asked, to which one are you answering ?
> The first ?
> If possible, can you point the paragraph ?
>
> Thanks
>
>
> On Sunday, May 28, 2017, Oleg Kalnichevski  wrote:
>
>> On Sat, 2017-05-20 at 16:31 +0200, Philippe Mouawad wrote:
>> > Hello,
>> > Any thoughts on that ?
>> >
>>
>> Hi Philippe
>>
>> This is perfectly legal. See
>>
>> https://www.ietf.org/rfc/rfc1341.txt
>>
>> Oleg
>>
>>
>>
>> > Thx
>> >
>> > On Wednesday, April 19, 2017, Philippe Mouawad > > l.com>
>> > wrote:
>> >
>> > > Hello,
>> > > Anybody has an idea about that ?
>> > > Thanks
>> > >
>> > > On Mon, Apr 17, 2017 at 10:50 PM, Philippe Mouawad <
>> > > philippe.moua...@gmail.com
>> > > >
>> > > wrote:
>> > >
>> > > > Hello,
>> > > > At JMeter we have a bug report (https://bz.apache.org/bugzill
>> > > > a/show_bug.cgi?id=60800) related to Multipart Form POST request
>> > > >
>> > > > A user reports that he has an issue with a request created by
>> > > > JMeter due
>> > > > to the presence in Request Headers of "charset=US-ASCII" at end
>> > > > of boundary
>> > > > in Content-Type.
>> > > >
>> > > > ---
>> > > > -
>> > > > POST http://localhost:8081/
>> > > >
>> > > > POST data:
>> > > > --5v5So93EEOXPO8DIg4kmR-vfmsbimn
>> > > > Content-Disposition: form-data; name="toto"
>> > > >
>> > > > titi
>> > > > --5v5So93EEOXPO8DIg4kmR-vfmsbimn--
>> > > >
>> > > >
>> > > > *Request Headers:*
>> > > > Connection: keep-alive
>> > > > Content-Length: 123
>> > > > *Content-Type: multipart/form-data;
>> > > > boundary=5v5So93EEOXPO8DIg4kmR-vfmsbimn; charset=US-ASCII*
>> > > > Host: localhost:8081
>> > > > User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
>> > > >
>> > > > ---
>> > > > -
>> > > >
>> > > > The code is created through (https://github.com/apache/jme
>> > > > ter/blob/trunk/src/protocol/http/org/apache/jmeter/
>> > > > protocol/http/sampler/HTTPHC4Impl.java#L1201):
>> > > >
>> > > > 1/MultipartEntityBuilder multipartEntityBuilder =
>> > > > MultipartEntityBuilder.create();
>> > > >
>> > > > 2/ As not Content Type is set in GUI, we default to US-ASCII so
>> > > > call:
>> > > > multipartEntityBuilder.setCharset("US-ASCII");
>> > > >
>> > > > 3/
>> > > > multipartEntityBuilder.setLaxMode();
>> > > >
>> > > > 4/ For every parameter:
>> > > > StringBody stringBody = new
>> > > > StringBody(arg.getValue(),
>> > > > ContentType.create("text/plain", charset));
>> > > > FormBodyPart formPart =
>> > > > FormBodyPartBuilder.create(
>> > > > parameterName, stringBody).build();
>> > > > multipartEntityBuilder.addPart(formPart);
>> > > >
>> > > > 5/
>> > > > HttpEntity entity = multipartEntityBuilder.build();
>> > > > post.setEntity(entity);
>> > > >
>> > > >
>> > > > So my questions are the following:
>> > > > 1/ Is it correct to add this charset part ?
>> > > > 2/ Could you point me to the reference part of RFC that mentions
>> > > > this ?
>> > > > 3/ Is it correct to avoid setting charset in this case in API
>> > > > which would
>> > > > lead to such request instead ?
>> > > >
>> > > >
>> > > >
>> > > > POST http://localhost:8081/
>> > > >
>> > > > POST data:
>> > > > --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
>> > > > Content-Disposition: form-data; name="toto"
>> > > >
>> > > > titi
>> > > > --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr--
>> > > >
>> > > > Request Headers:
>> > > > Connection: keep-alive
>> > > > Content-Length: 135
>> > > > Content-Type: multipart/form-data; boundary=xjNHd_UhEEpqC2ZoFCpGR
>> > > > zYzHK90ljsdpfTr
>> > > > Host: localhost:8081
>> > > > User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
>> > > >
>> > > >
>> > > > Thanks for your help
>> > > > Regards
>> > > > Philippe M.
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Cordialement.
>> > > Philippe Mouawad.
>> > >
>> > >
>> > >
>> >
>> >
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: MultipartEntityBuilder and Charset US-ASCII

[Philippe Mouawad]

Hi Oleg,
>From the 3 questions I asked, to which one are you answering ?
The first ?
If possible, can you point the paragraph ?

Thanks

On Sunday, May 28, 2017, Oleg Kalnichevski  wrote:

> On Sat, 2017-05-20 at 16:31 +0200, Philippe Mouawad wrote:
> > Hello,
> > Any thoughts on that ?
> >
>
> Hi Philippe
>
> This is perfectly legal. See
>
> https://www.ietf.org/rfc/rfc1341.txt
>
> Oleg
>
>
>
> > Thx
> >
> > On Wednesday, April 19, 2017, Philippe Mouawad  > l.com>
> > wrote:
> >
> > > Hello,
> > > Anybody has an idea about that ?
> > > Thanks
> > >
> > > On Mon, Apr 17, 2017 at 10:50 PM, Philippe Mouawad <
> > > philippe.moua...@gmail.com 
> > >  ');>>
> > > wrote:
> > >
> > > > Hello,
> > > > At JMeter we have a bug report (https://bz.apache.org/bugzill
> > > > a/show_bug.cgi?id=60800) related to Multipart Form POST request
> > > >
> > > > A user reports that he has an issue with a request created by
> > > > JMeter due
> > > > to the presence in Request Headers of "charset=US-ASCII" at end
> > > > of boundary
> > > > in Content-Type.
> > > >
> > > > ---
> > > > -
> > > > POST http://localhost:8081/
> > > >
> > > > POST data:
> > > > --5v5So93EEOXPO8DIg4kmR-vfmsbimn
> > > > Content-Disposition: form-data; name="toto"
> > > >
> > > > titi
> > > > --5v5So93EEOXPO8DIg4kmR-vfmsbimn--
> > > >
> > > >
> > > > *Request Headers:*
> > > > Connection: keep-alive
> > > > Content-Length: 123
> > > > *Content-Type: multipart/form-data;
> > > > boundary=5v5So93EEOXPO8DIg4kmR-vfmsbimn; charset=US-ASCII*
> > > > Host: localhost:8081
> > > > User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
> > > >
> > > > ---
> > > > -
> > > >
> > > > The code is created through (https://github.com/apache/jme
> > > > ter/blob/trunk/src/protocol/http/org/apache/jmeter/
> > > > protocol/http/sampler/HTTPHC4Impl.java#L1201):
> > > >
> > > > 1/MultipartEntityBuilder multipartEntityBuilder =
> > > > MultipartEntityBuilder.create();
> > > >
> > > > 2/ As not Content Type is set in GUI, we default to US-ASCII so
> > > > call:
> > > > multipartEntityBuilder.setCharset("US-ASCII");
> > > >
> > > > 3/
> > > > multipartEntityBuilder.setLaxMode();
> > > >
> > > > 4/ For every parameter:
> > > > StringBody stringBody = new
> > > > StringBody(arg.getValue(),
> > > > ContentType.create("text/plain", charset));
> > > > FormBodyPart formPart =
> > > > FormBodyPartBuilder.create(
> > > > parameterName, stringBody).build();
> > > > multipartEntityBuilder.addPart(formPart);
> > > >
> > > > 5/
> > > > HttpEntity entity = multipartEntityBuilder.build();
> > > > post.setEntity(entity);
> > > >
> > > >
> > > > So my questions are the following:
> > > > 1/ Is it correct to add this charset part ?
> > > > 2/ Could you point me to the reference part of RFC that mentions
> > > > this ?
> > > > 3/ Is it correct to avoid setting charset in this case in API
> > > > which would
> > > > lead to such request instead ?
> > > >
> > > >
> > > >
> > > > POST http://localhost:8081/
> > > >
> > > > POST data:
> > > > --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
> > > > Content-Disposition: form-data; name="toto"
> > > >
> > > > titi
> > > > --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr--
> > > >
> > > > Request Headers:
> > > > Connection: keep-alive
> > > > Content-Length: 135
> > > > Content-Type: multipart/form-data; boundary=xjNHd_UhEEpqC2ZoFCpGR
> > > > zYzHK90ljsdpfTr
> > > > Host: localhost:8081
> > > > User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
> > > >
> > > >
> > > > Thanks for your help
> > > > Regards
> > > > Philippe M.
> > > >
> > >
> > >
> > >
> > > --
> > > Cordialement.
> > > Philippe Mouawad.
> > >
> > >
> > >
> >
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: MultipartEntityBuilder and Charset US-ASCII

[Philippe Mouawad]

Hello Gary,
No unfortunately.
I was hoping to get some lights from the mailing list here.


Regards

On Mon, May 22, 2017 at 6:46 AM, Gary Gregory 
wrote:

> Philippe,
>
> Have you solved this?
>
> Gary
>
>
> On May 20, 2017 7:31 AM, "Philippe Mouawad" 
> wrote:
>
> Hello,
> Any thoughts on that ?
>
> Thx
>
> On Wednesday, April 19, 2017, Philippe Mouawad  >
> wrote:
>
> > Hello,
> > Anybody has an idea about that ?
> > Thanks
> >
> > On Mon, Apr 17, 2017 at 10:50 PM, Philippe Mouawad <
> > philippe.moua...@gmail.com
> > > wrote:
> >
> >> Hello,
> >> At JMeter we have a bug report (https://bz.apache.org/bugzill
> >> a/show_bug.cgi?id=60800) related to Multipart Form POST request
> >>
> >> A user reports that he has an issue with a request created by JMeter due
> >> to the presence in Request Headers of "charset=US-ASCII" at end of
> boundary
> >> in Content-Type.
> >>
> >> 
> 
> >> POST http://localhost:8081/
> >>
> >> POST data:
> >> --5v5So93EEOXPO8DIg4kmR-vfmsbimn
> >> Content-Disposition: form-data; name="toto"
> >>
> >> titi
> >> --5v5So93EEOXPO8DIg4kmR-vfmsbimn--
> >>
> >>
> >> *Request Headers:*
> >> Connection: keep-alive
> >> Content-Length: 123
> >> *Content-Type: multipart/form-data;
> >> boundary=5v5So93EEOXPO8DIg4kmR-vfmsbimn; charset=US-ASCII*
> >> Host: localhost:8081
> >> User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
> >>
> >> 
> 
> >>
> >> The code is created through (https://github.com/apache/jme
> >> ter/blob/trunk/src/protocol/http/org/apache/jmeter/
> >> protocol/http/sampler/HTTPHC4Impl.java#L1201):
> >>
> >> 1/MultipartEntityBuilder multipartEntityBuilder =
> >> MultipartEntityBuilder.create();
> >>
> >> 2/ As not Content Type is set in GUI, we default to US-ASCII so call:
> >> multipartEntityBuilder.setCharset("US-ASCII");
> >>
> >> 3/
> >> multipartEntityBuilder.setLaxMode();
> >>
> >> 4/ For every parameter:
> >> StringBody stringBody = new StringBody(arg.getValue(),
> >> ContentType.create("text/plain", charset));
> >> FormBodyPart formPart = FormBodyPartBuilder.create(
> >> parameterName, stringBody).build();
> >> multipartEntityBuilder.addPart(formPart);
> >>
> >> 5/
> >> HttpEntity entity = multipartEntityBuilder.build();
> >> post.setEntity(entity);
> >>
> >>
> >> So my questions are the following:
> >> 1/ Is it correct to add this charset part ?
> >> 2/ Could you point me to the reference part of RFC that mentions this ?
> >> 3/ Is it correct to avoid setting charset in this case in API which
> would
> >> lead to such request instead ?
> >>
> >>
> >>
> >> POST http://localhost:8081/
> >>
> >> POST data:
> >> --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
> >> Content-Disposition: form-data; name="toto"
> >>
> >> titi
> >> --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr--
> >>
> >> Request Headers:
> >> Connection: keep-alive
> >> Content-Length: 135
> >> Content-Type: multipart/form-data; boundary=xjNHd_UhEEpqC2ZoFCpGR
> >> zYzHK90ljsdpfTr
> >> Host: localhost:8081
> >> User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
> >>
> >>
> >> Thanks for your help
> >> Regards
> >> Philippe M.
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
> >
> >
>
> --
> Cordialement.
> Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: Brotli compression

[Philippe Mouawad]

Hi,
For info, done and release in last commons-compress.

Regards

On Sunday, April 30, 2017, Gary Gregory  wrote:

> Should at least just bridge to the decompression code from Google for now?
>
> Gary
>
> On Thu, Apr 13, 2017 at 5:48 AM, Philippe Mouawad <
> philippe.moua...@gmail.com > wrote:
>
> > Hello,
> > There appear to be a java decoder as per:
> >
> >
> > https://github.com/google/brotli/issues/466
> >
> >
> >
> > https://github.com/google/brotli/tree/master/java/org/brotli
> >
> > Httpd 2.4 last release support Brotli  now on server side.
> >
> > Regards
> > On Wednesday, November 16, 2016, Gary Gregory  >
> > wrote:
> >
> > > There is Java implementation here https://github.com/meteogroup/
> jbrotli
> > > but
> > > it is not 100% Java.
> > >
> > > Gary
> > >
> > > On Tue, Nov 15, 2016 at 11:33 PM, Philippe Mouawad <
> > > philippe.moua...@gmail.com  > wrote:
> > >
> > > > Hi Gary,
> > > > I created :
> > > > https://issues.apache.org/jira/browse/COMPRESS-370
> > > >
> > > > Regards
> > > >
> > > > On Wed, Nov 16, 2016 at 12:14 AM, Gary Gregory <
> garydgreg...@gmail.com 
> > > >
> > > > wrote:
> > > >
> > > > > I do not think so. This would be interesting to add to Commons
> > Compress
> > > > > though.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Nov 15, 2016 11:51 AM, "Philippe Mouawad" <
> > > philippe.moua...@gmail.com  
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > > Is Brotli (https://en.wikipedia.org/wiki/Brotli) compression
> > > supported
> > > > > by
> > > > > > HttpCore/HttpClient ?
> > > > > >
> > > > > > Thanks
> > > > > > Regards
> > > > > > Philippe
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cordialement.
> > > > Philippe Mouawad.
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com   |
> ggreg...@apache.org 
> > > 
> > > Java Persistence with Hibernate, Second Edition
> > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2
> b8>
> > >
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > > 1617290459>
> > > JUnit in Action, Second Edition
> > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4
> > 18%22
> > > >
> > >
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > > 1935182021>
> > > Spring Batch in Action
> > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> > > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> > > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> > > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> > > <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > > 1935182951>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com  | ggreg...@apache.org
> 
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


-- 
Cordialement.
Philippe Mouawad.

Re: MultipartEntityBuilder and Charset US-ASCII

[Philippe Mouawad]

Hello,
Any thoughts on that ?

Thx

On Wednesday, April 19, 2017, Philippe Mouawad 
wrote:

> Hello,
> Anybody has an idea about that ?
> Thanks
>
> On Mon, Apr 17, 2017 at 10:50 PM, Philippe Mouawad <
> philippe.moua...@gmail.com
> > wrote:
>
>> Hello,
>> At JMeter we have a bug report (https://bz.apache.org/bugzill
>> a/show_bug.cgi?id=60800) related to Multipart Form POST request
>>
>> A user reports that he has an issue with a request created by JMeter due
>> to the presence in Request Headers of "charset=US-ASCII" at end of boundary
>> in Content-Type.
>>
>> 
>> POST http://localhost:8081/
>>
>> POST data:
>> --5v5So93EEOXPO8DIg4kmR-vfmsbimn
>> Content-Disposition: form-data; name="toto"
>>
>> titi
>> --5v5So93EEOXPO8DIg4kmR-vfmsbimn--
>>
>>
>> *Request Headers:*
>> Connection: keep-alive
>> Content-Length: 123
>> *Content-Type: multipart/form-data;
>> boundary=5v5So93EEOXPO8DIg4kmR-vfmsbimn; charset=US-ASCII*
>> Host: localhost:8081
>> User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
>>
>> 
>>
>> The code is created through (https://github.com/apache/jme
>> ter/blob/trunk/src/protocol/http/org/apache/jmeter/
>> protocol/http/sampler/HTTPHC4Impl.java#L1201):
>>
>> 1/MultipartEntityBuilder multipartEntityBuilder =
>> MultipartEntityBuilder.create();
>>
>> 2/ As not Content Type is set in GUI, we default to US-ASCII so call:
>> multipartEntityBuilder.setCharset("US-ASCII");
>>
>> 3/
>> multipartEntityBuilder.setLaxMode();
>>
>> 4/ For every parameter:
>> StringBody stringBody = new StringBody(arg.getValue(),
>> ContentType.create("text/plain", charset));
>> FormBodyPart formPart = FormBodyPartBuilder.create(
>> parameterName, stringBody).build();
>> multipartEntityBuilder.addPart(formPart);
>>
>> 5/
>> HttpEntity entity = multipartEntityBuilder.build();
>> post.setEntity(entity);
>>
>>
>> So my questions are the following:
>> 1/ Is it correct to add this charset part ?
>> 2/ Could you point me to the reference part of RFC that mentions this ?
>> 3/ Is it correct to avoid setting charset in this case in API which would
>> lead to such request instead ?
>>
>>
>>
>> POST http://localhost:8081/
>>
>> POST data:
>> --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
>> Content-Disposition: form-data; name="toto"
>>
>> titi
>> --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr--
>>
>> Request Headers:
>> Connection: keep-alive
>> Content-Length: 135
>> Content-Type: multipart/form-data; boundary=xjNHd_UhEEpqC2ZoFCpGR
>> zYzHK90ljsdpfTr
>> Host: localhost:8081
>> User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
>>
>>
>> Thanks for your help
>> Regards
>> Philippe M.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Any reason for not using java.util.zip.DeflaterInputStream

[Philippe Mouawad]

Hi Oleg,
Thanks for your answer.

I didn't request for a change, I just wanted to know the historical reason
for that.
After making additional tests I see it breaks much more frequently that the
HC4 class.

Thanks
Regards

On Mon, May 1, 2017 at 4:05 PM, Oleg Kalnichevski  wrote:

> On Sun, 2017-04-30 at 23:02 +0200, Philippe Mouawad wrote:
> > Why not.
> > But why not just use the Java class instead of maintaining a custom
> > class
> > in HC ?
> >
>
> Philippe
>
> I replaced the existing implementation [1] with that from JRE and it
> broke our deflate compression tests [2].
>
> I also see little urgency in replacing custom DeflateInputStream given
> it uses standard Deflater class internally and is relatively small.
>
> However anyone willing to invest time into fixing the problem is very
> welcome to do so and raise a PR once the cause of test breakage is
> identified and resolved.
>
> Oleg
>
> [1] https://github.com/apache/httpclient/blob/trunk/httpclient5/src/mai
> n/java/org/apache/hc/client5/http/entity/DeflateInputStream.java
>
> [2] https://github.com/apache/httpclient/blob/trunk/httpclient5/src/tes
> t/java/org/apache/hc/client5/http/entity/TestDeflate.java
>
> > Thanks
> >
> > On Sun, Apr 30, 2017 at 10:22 PM, Gary Gregory  > m>
> > wrote:
> >
> > > Maybe we should make it pluggable with an optional impl using
> > > Commons
> > > Compress?
> > >
> > > Gary
> > >
> > > On Apr 30, 2017 1:02 PM, "Philippe Mouawad" 
> > > wrote:
> > >
> > > > Hello,
> > > > For Deflate response encoded content, HC4 has a custom
> > > > implementation
> > > > org.apache.http.client.entity.DeflateInputStream
> > > >
> > > > Is there any reason for not using
> > > > java.util.zip.DeflaterInputStream
> > > > available since Java 6.
> > > >
> > > >
> > > > Thanks
> > > > Regards
> > > > @philmdot
> > > >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Re: Any reason for not using java.util.zip.DeflaterInputStream

[Philippe Mouawad]

Why not.
But why not just use the Java class instead of maintaining a custom class
in HC ?

Thanks

On Sun, Apr 30, 2017 at 10:22 PM, Gary Gregory 
wrote:

> Maybe we should make it pluggable with an optional impl using Commons
> Compress?
>
> Gary
>
> On Apr 30, 2017 1:02 PM, "Philippe Mouawad"  wrote:
>
> > Hello,
> > For Deflate response encoded content, HC4 has a custom implementation
> > org.apache.http.client.entity.DeflateInputStream
> >
> > Is there any reason for not using java.util.zip.DeflaterInputStream
> > available since Java 6.
> >
> >
> > Thanks
> > Regards
> > @philmdot
> >
>



-- 
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie

UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>

UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>

Any reason for not using java.util.zip.DeflaterInputStream

[Philippe Mouawad]

Hello,
For Deflate response encoded content, HC4 has a custom implementation
org.apache.http.client.entity.DeflateInputStream

Is there any reason for not using java.util.zip.DeflaterInputStream
available since Java 6.


Thanks
Regards
@philmdot

Re: MultipartEntityBuilder and Charset US-ASCII

[Philippe Mouawad]

Hello,
Anybody has an idea about that ?
Thanks

On Mon, Apr 17, 2017 at 10:50 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> At JMeter we have a bug report (https://bz.apache.org/
> bugzilla/show_bug.cgi?id=60800) related to Multipart Form POST request
>
> A user reports that he has an issue with a request created by JMeter due
> to the presence in Request Headers of "charset=US-ASCII" at end of boundary
> in Content-Type.
>
> 
> POST http://localhost:8081/
>
> POST data:
> --5v5So93EEOXPO8DIg4kmR-vfmsbimn
> Content-Disposition: form-data; name="toto"
>
> titi
> --5v5So93EEOXPO8DIg4kmR-vfmsbimn--
>
>
> *Request Headers:*
> Connection: keep-alive
> Content-Length: 123
> *Content-Type: multipart/form-data;
> boundary=5v5So93EEOXPO8DIg4kmR-vfmsbimn; charset=US-ASCII*
> Host: localhost:8081
> User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
>
> 
>
> The code is created through (https://github.com/apache/
> jmeter/blob/trunk/src/protocol/http/org/apache/
> jmeter/protocol/http/sampler/HTTPHC4Impl.java#L1201):
>
> 1/MultipartEntityBuilder multipartEntityBuilder =
> MultipartEntityBuilder.create();
>
> 2/ As not Content Type is set in GUI, we default to US-ASCII so call:
> multipartEntityBuilder.setCharset("US-ASCII");
>
> 3/
> multipartEntityBuilder.setLaxMode();
>
> 4/ For every parameter:
> StringBody stringBody = new StringBody(arg.getValue(),
> ContentType.create("text/plain", charset));
> FormBodyPart formPart = FormBodyPartBuilder.create(
> parameterName, stringBody).build();
> multipartEntityBuilder.addPart(formPart);
>
> 5/
> HttpEntity entity = multipartEntityBuilder.build();
> post.setEntity(entity);
>
>
> So my questions are the following:
> 1/ Is it correct to add this charset part ?
> 2/ Could you point me to the reference part of RFC that mentions this ?
> 3/ Is it correct to avoid setting charset in this case in API which would
> lead to such request instead ?
>
>
>
> POST http://localhost:8081/
>
> POST data:
> --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
> Content-Disposition: form-data; name="toto"
>
> titi
> --xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr--
>
> Request Headers:
> Connection: keep-alive
> Content-Length: 135
> Content-Type: multipart/form-data; boundary=xjNHd_
> UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
> Host: localhost:8081
> User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)
>
>
> Thanks for your help
> Regards
> Philippe M.
>



-- 
Cordialement.
Philippe Mouawad.

MultipartEntityBuilder and Charset US-ASCII

[Philippe Mouawad]

Hello,
At JMeter we have a bug report (
https://bz.apache.org/bugzilla/show_bug.cgi?id=60800) related to Multipart
Form POST request

A user reports that he has an issue with a request created by JMeter due to
the presence in Request Headers of "charset=US-ASCII" at end of boundary in
Content-Type.


POST http://localhost:8081/

POST data:
--5v5So93EEOXPO8DIg4kmR-vfmsbimn
Content-Disposition: form-data; name="toto"

titi
--5v5So93EEOXPO8DIg4kmR-vfmsbimn--


*Request Headers:*
Connection: keep-alive
Content-Length: 123
*Content-Type: multipart/form-data;
boundary=5v5So93EEOXPO8DIg4kmR-vfmsbimn; charset=US-ASCII*
Host: localhost:8081
User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)



The code is created through (
https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L1201
):

1/MultipartEntityBuilder multipartEntityBuilder =
MultipartEntityBuilder.create();

2/ As not Content Type is set in GUI, we default to US-ASCII so call:
multipartEntityBuilder.setCharset("US-ASCII");

3/
multipartEntityBuilder.setLaxMode();

4/ For every parameter:
StringBody stringBody = new StringBody(arg.getValue(),
ContentType.create("text/plain", charset));
FormBodyPart formPart = FormBodyPartBuilder.create(
parameterName, stringBody).build();
multipartEntityBuilder.addPart(formPart);

5/
HttpEntity entity = multipartEntityBuilder.build();
post.setEntity(entity);


So my questions are the following:
1/ Is it correct to add this charset part ?
2/ Could you point me to the reference part of RFC that mentions this ?
3/ Is it correct to avoid setting charset in this case in API which would
lead to such request instead ?



POST http://localhost:8081/

POST data:
--xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
Content-Disposition: form-data; name="toto"

titi
--xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr--

Request Headers:
Connection: keep-alive
Content-Length: 135
Content-Type: multipart/form-data;
boundary=xjNHd_UhEEpqC2ZoFCpGRzYzHK90ljsdpfTr
Host: localhost:8081
User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_121)


Thanks for your help
Regards
Philippe M.

Re: Brotli compression

[Philippe Mouawad]

Hello,
There appear to be a java decoder as per:


https://github.com/google/brotli/issues/466



https://github.com/google/brotli/tree/master/java/org/brotli

Httpd 2.4 last release support Brotli  now on server side.

Regards
On Wednesday, November 16, 2016, Gary Gregory 
wrote:

> There is Java implementation here https://github.com/meteogroup/jbrotli
> but
> it is not 100% Java.
>
> Gary
>
> On Tue, Nov 15, 2016 at 11:33 PM, Philippe Mouawad <
> philippe.moua...@gmail.com > wrote:
>
> > Hi Gary,
> > I created :
> > https://issues.apache.org/jira/browse/COMPRESS-370
> >
> > Regards
> >
> > On Wed, Nov 16, 2016 at 12:14 AM, Gary Gregory  >
> > wrote:
> >
> > > I do not think so. This would be interesting to add to Commons Compress
> > > though.
> > >
> > > Gary
> > >
> > > On Nov 15, 2016 11:51 AM, "Philippe Mouawad" <
> philippe.moua...@gmail.com 
> > >
> > > wrote:
> > >
> > > > Hello,
> > > > Is Brotli (https://en.wikipedia.org/wiki/Brotli) compression
> supported
> > > by
> > > > HttpCore/HttpClient ?
> > > >
> > > > Thanks
> > > > Regards
> > > > Philippe
> > > >
> > >
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com  | ggreg...@apache.org
> 
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


-- 
Cordialement.
Philippe Mouawad.

Re: Support HTTP/2 protocol

[Philippe Mouawad]

Thanks Oleg for your answer.
Regarding JMeter, having to wait for Java 9 may not be feasible as we'll be
just upgrading to Java 8 in next release but I think we'll have to support
Java8 for at least 1 year or 2.
Java9 will also most probably require some important work due to modules
and adoption (not only for JMeter) may take some time.


Regards

On Thu, Jan 26, 2017 at 4:15 PM, Oleg Kalnichevski  wrote:

> On Thu, 2017-01-26 at 14:32 +0100, Philippe Mouawad wrote:
> > Hello ,
> > Oleg kindly proposed to help JMeter project in adding HTTP/2 support.
> >
> > We have started this thread to work on design.
> >
> > As per Andrei remark, it seems ALPN is not yet supported by current
> > HTTPClient 5.x version.
> > Is there some visibility on its support ?
> >
>
>
> ALPN will be supported as soon as it is supported by the Java platform
> (which is not going to happen until Java 9).
>
> ALPN can be used to advertise server protocol capabilities at the time
> of SSL handshake and allow clients to pick the desired protocol from
> the list of supported protocols. If one knows supported protocols
> beforehand ALPN is completely useless. Clients can go straight to using
> HTTP/2 if the server is known to support it.
>
> In the next release of HttpCore I would like to add protocol detection
> logic to enable endpoints to detect HTTP protocol version by examining
> the first packet received from the opposite endpoint. This in my
> opinion would be a much more practical feature. ALPN presently is very
> low on my priority list.
>
> Having said that ALPN support contribution would be welcome if someone
> is willing to develop it.
>
> Oleg
>
>
>
> > Thanks for your help.
> > Regards
> >
> > On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilko  wrote:
> >
> > > Hi,
> > >
> > > From my experiments, I see that lack of two specific features make
> > > it
> > > not useful. According to https://hc.apache.org/news.html:
> > >
> > >   * No ALPN support yet
> > >   * no connection upgrade
> > >
> > > Especially ALPN part is crucial for protocol functioning. Is there
> > > any
> > > ETA from Oleg when it will become available?
> > >
> > >
> > > In general, we can start designing the "synchronous way" solution.
> > > From
> > > my understanding, it is doable and will be good enough for the
> > > beginning.
> > >
> > >
> > > Andrey Pokhilko
> > >
> > > On 25.01.2017 23:38, Philippe Mouawad wrote:
> > > > Hello
> > > > I'd like to start a thread on this particular item for which an
> > >
> > > enhancement
> > > > exists:
> > > >
> > > >- https://bz.apache.org/bugzilla/show_bug.cgi?id=59847
> > > >
> > > > The aim of this thread is to discuss, throw ideas on how we could
> > >
> > > implement
> > > > this in JMeter.
> > > >
> > > > Oleg K. from HttpComponents project has nicely proposed to help
> > > > on it.
> > > >
> > > > I see at least 2 parts in this item:
> > > >
> > > >- The Sampler
> > > >- The Recorder
> > > >
> > > >
> > > >
> > > > *Sampler:*
> > > > We have 2 options:
> > > >
> > > >- build a usual "synchronous" sampler similar to HTTP:
> > > >   - Is this realistic ?
> > > >   - Does it perform well ?
> > > >   - + : It should not be too complex
> > > >- build a new "Asynchronous sampler":
> > > >   - Is this realistic ?
> > > >   - + We could gain more performance
> > > >   - - It is a huge piece of work as we need to change JMeter
> > > > model
> > > >
> > > > *Recorder:*
> > > >
> > > > I think we need to introduce a new more generic Recorder as the
> > > > current
> > > > Test Script Recorder is too tightly linked to HTTP 1.X protocol
> > > >
> > > >
> > > > Regards
> > > > Philippe M.
> > > > @philmdot
> > > >
> > >
> > >
> >
> >
>



-- 
Cordialement.
Philippe Mouawad.

Re: Support HTTP/2 protocol

[Philippe Mouawad]

Hello ,
Oleg kindly proposed to help JMeter project in adding HTTP/2 support.

We have started this thread to work on design.

As per Andrei remark, it seems ALPN is not yet supported by current
HTTPClient 5.x version.
Is there some visibility on its support ?

Thanks for your help.
Regards

On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilko  wrote:

> Hi,
>
> From my experiments, I see that lack of two specific features make it
> not useful. According to https://hc.apache.org/news.html:
>
>   * No ALPN support yet
>   * no connection upgrade
>
> Especially ALPN part is crucial for protocol functioning. Is there any
> ETA from Oleg when it will become available?
>
>
> In general, we can start designing the "synchronous way" solution. From
> my understanding, it is doable and will be good enough for the beginning.
>
>
> Andrey Pokhilko
>
> On 25.01.2017 23:38, Philippe Mouawad wrote:
> > Hello
> > I'd like to start a thread on this particular item for which an
> enhancement
> > exists:
> >
> >- https://bz.apache.org/bugzilla/show_bug.cgi?id=59847
> >
> > The aim of this thread is to discuss, throw ideas on how we could
> implement
> > this in JMeter.
> >
> > Oleg K. from HttpComponents project has nicely proposed to help on it.
> >
> > I see at least 2 parts in this item:
> >
> >- The Sampler
> >- The Recorder
> >
> >
> >
> > *Sampler:*
> > We have 2 options:
> >
> >- build a usual "synchronous" sampler similar to HTTP:
> >   - Is this realistic ?
> >   - Does it perform well ?
> >   - + : It should not be too complex
> >- build a new "Asynchronous sampler":
> >   - Is this realistic ?
> >   - + We could gain more performance
> >   - - It is a huge piece of work as we need to change JMeter model
> >
> > *Recorder:*
> >
> > I think we need to introduce a new more generic Recorder as the current
> > Test Script Recorder is too tightly linked to HTTP 1.X protocol
> >
> >
> > Regards
> > Philippe M.
> > @philmdot
> >
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Brotli compression

[Philippe Mouawad]

Hi Gary,
I created :
https://issues.apache.org/jira/browse/COMPRESS-370

Regards

On Wed, Nov 16, 2016 at 12:14 AM, Gary Gregory 
wrote:

> I do not think so. This would be interesting to add to Commons Compress
> though.
>
> Gary
>
> On Nov 15, 2016 11:51 AM, "Philippe Mouawad" 
> wrote:
>
> > Hello,
> > Is Brotli (https://en.wikipedia.org/wiki/Brotli) compression supported
> by
> > HttpCore/HttpClient ?
> >
> > Thanks
> > Regards
> > Philippe
> >
>



-- 
Cordialement.
Philippe Mouawad.

Re: SSL Handshake : timing and timeout

[Philippe Mouawad]

Hello,
Maybe my thinking is stupid, but isn't there some use cases where SOcket
does not timeout but a loop can occur in handshake ?
My idea is to have a timeout on the handshake process.

Regards

On Sat, Nov 12, 2016 at 4:26 PM, Oleg Kalnichevski  wrote:

> On Fri, 2016-11-11 at 11:01 +0100, Stefan Magnus Landrø wrote:
> > True. The way SSL sockets are created is complex stuff. They are layered
> > and I believe the handshake is async - maybe Oleg could clarify?
> >
>
> There is nothing special or unusual about SSL/TLS handshakes. They
> involve multiple IP packet exchanges over a TCP connection. Standard
> socket settings fully apply.
>
> Oleg
>
> > Anyways - We ran into an issue a few years ago with an SSL handshake
> taking
> > for ever (a switch was dropping packets of a certain size ... ), and
> > tracked our hanging threads down to blocking because the SoTimeout was
> set
> > to 0 by default. Changing this prevented threads from hanging for ever.
> >
> > Ref javadoc:
> >
> > Determines the default socket timeout value for non-blocking I/O
> operations.
> >
> > 2016-11-11 10:01 GMT+01:00 Philippe Mouawad  >:
> >
> > > Thanks but I see not property related to Ssl Handshake timeout.
> > >
> > > Regards
> > >
> > > On Friday, November 11, 2016, Stefan Magnus Landrø <
> > > stefan.lan...@gmail.com>
> > > wrote:
> > >
> > > > https://hc.apache.org/httpcomponents-client-ga/
> > > > httpclient/apidocs/org/apache/http/impl/client/
> HttpClientBuilder.html#
> > > > setDefaultSocketConfig(org.apache.http.config.SocketConfig)
> > > >
> > > > 2016-11-11 9:34 GMT+01:00 Philippe Mouawad <
> philippe.moua...@gmail.com
> > > > >:
> > > >
> > > > > Thank you Stefan
> > > > > Could you point me to some doc ?
> > > > >
> > >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Brotli compression

[Philippe Mouawad]

Hello,
Is Brotli (https://en.wikipedia.org/wiki/Brotli) compression supported by
HttpCore/HttpClient ?

Thanks
Regards
Philippe

Re: SSL Handshake : timing and timeout

[Philippe Mouawad]

Thanks but I see not property related to Ssl Handshake timeout.

Regards

On Friday, November 11, 2016, Stefan Magnus Landrø 
wrote:

> https://hc.apache.org/httpcomponents-client-ga/
> httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#
> setDefaultSocketConfig(org.apache.http.config.SocketConfig)
>
> 2016-11-11 9:34 GMT+01:00 Philippe Mouawad  >:
>
> > Thank you Stefan
> > Could you point me to some doc ?
> >
> > Thanks
> >
> > On Fri, Nov 11, 2016 at 9:20 AM, Stefan Magnus Landrø <
> > stefan.lan...@gmail.com > wrote:
> >
> > >
> > >
> > > Sendt fra min iPhone
> > >
> > > > Den 11. nov. 2016 kl. 00.25 skrev Philippe Mouawad <
> > pmoua...@apache.org 
> > > >:
> > > >
> > > > Hello,
> > > > Is there a way in HttpClient/HttpCore to compute the time taken by
> SSL
> > > > Handshake ?
> > > > And timeout handshake ?
> > >
> > > Use
> > > socketoptions
> > > >
> > > > Thank you
> > > > Regards
> > > > Philippe M.
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> > >
> > >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>
>
>
> --
> BEKK Open
> http://open.bekk.no
>
> TesTcl - a unit test framework for iRules
> http://testcl.com
>


-- 
Cordialement.
Philippe Mouawad.

Re: SSL Handshake : timing and timeout

[Philippe Mouawad]

Thank you Stefan
Could you point me to some doc ?

Thanks

On Fri, Nov 11, 2016 at 9:20 AM, Stefan Magnus Landrø <
stefan.lan...@gmail.com> wrote:

>
>
> Sendt fra min iPhone
>
> > Den 11. nov. 2016 kl. 00.25 skrev Philippe Mouawad  >:
> >
> > Hello,
> > Is there a way in HttpClient/HttpCore to compute the time taken by SSL
> > Handshake ?
> > And timeout handshake ?
>
> Use
> socketoptions
> >
> > Thank you
> > Regards
> > Philippe M.
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

SSL Handshake : timing and timeout

[Philippe Mouawad]

Hello,
Is there a way in HttpClient/HttpCore to compute the time taken by SSL
Handshake ?
And timeout handshake ?

Thank you
Regards
Philippe M.

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

Hi Oleg,
If you look at :
https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
You can see that this encoding can break some applications.

If I read https://en.wikipedia.org/wiki/Percent-encoding#The_
application.2Fx-www-form-urlencoded_type


Which references https://tools.ietf.org/html/rfc1630
I understand @ is safe.

Regards



On Sun, Sep 18, 2016 at 5:04 PM, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 16:27 +0200, Philippe Mouawad wrote:
> > On Sunday, September 18, 2016, Oleg Kalnichevski 
> wrote:
> >
> > > On Sun, 2016-09-18 at 16:12 +0200, Philippe Mouawad wrote:
> > > > So is it a bug ? or a regular behaviour ?
> > > >
> > >
> > > We back to where we started. Why do you think it should not be encoded?
> >
> > it does not seem to be when using browser.
> > It should if it's in url but I am not sure it is reserved when located in
> > form parameter.
> > I don't fully understand the rfc documentation.
> >
>
> I can be easily wrong here but I am not aware of any RFC that defines
> composition of application/x-www-form-urlencoded content.
>
> As far as I know HttpClient presently emulates the behavior of
> java.net.URLEncoder. It also seems safer to me to rather encode too much
> and to encode too little.
>
> Oleg
>
> > Regards
> >
> > >
> > > Oleg
> > >
> > > > thanks
> > > >
> > > > On Sunday, September 18, 2016, Oleg Kalnichevski  > > > wrote:
> > > >
> > > > > On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > > > > > Hi Oleg,
> > > > > > Thanks for rapid answer.
> > > > > > Correct me if I am wrong but:
> > > > > > - URLENCODER is built from an or on UNRESERVED (which contains
> '_',
> > > '-',
> > > > > > '.', '*' and a-z, A-Z, 0-9.
> > > > > >
> > > > > > URLENCODER is passed as safechars in
> > > > > > private static String urlEncode(
> > > > > > final String content,
> > > > > > final Charset charset,
> > > > > > final BitSet safechars,
> > > > > > final boolean blankAsPlus)
> > > > > >
> > > > > >
> > > > > > @ is not part of the chars, so you end up in this part of
> algorithms
> > > > > right
> > > > > > ?:
> > > > > > } else {
> > > > > > buf.append("%");
> > > > > > final char hex1 =
> > > > > > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF,
> RADIX));
> > > > > > final char hex2 =
> > > > > > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > > > > > buf.append(hex1);
> > > > > > buf.append(hex2);
> > > > > > }
> > > > > >
> > > > > > And thus it gets URL encoded no ?
> > > > > >
> > > > >
> > > > > Yes, I was mistaken. Sorry about that.
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > >
> > > > > 
> -
> > > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > > 
> > > > > 
> > > > > For additional commands, e-mail: httpclient-users-help@hc.
> apache.org
> > > 
> > > > > 
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > > 
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > > 
> > >
> > >
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 16:12 +0200, Philippe Mouawad wrote:
> > So is it a bug ? or a regular behaviour ?
> >
>
> We back to where we started. Why do you think it should not be encoded?

it does not seem to be when using browser.
It should if it's in url but I am not sure it is reserved when located in
form parameter.
I don't fully understand the rfc documentation.

Regards

>
> Oleg
>
> > thanks
> >
> > On Sunday, September 18, 2016, Oleg Kalnichevski  > wrote:
> >
> > > On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > > > Hi Oleg,
> > > > Thanks for rapid answer.
> > > > Correct me if I am wrong but:
> > > > - URLENCODER is built from an or on UNRESERVED (which contains '_',
> '-',
> > > > '.', '*' and a-z, A-Z, 0-9.
> > > >
> > > > URLENCODER is passed as safechars in
> > > > private static String urlEncode(
> > > > final String content,
> > > > final Charset charset,
> > > > final BitSet safechars,
> > > > final boolean blankAsPlus)
> > > >
> > > >
> > > > @ is not part of the chars, so you end up in this part of algorithms
> > > right
> > > > ?:
> > > > } else {
> > > > buf.append("%");
> > > > final char hex1 =
> > > > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
> > > > final char hex2 =
> > > > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > > > buf.append(hex1);
> > > > buf.append(hex2);
> > > > }
> > > >
> > > > And thus it gets URL encoded no ?
> > > >
> > >
> > > Yes, I was mistaken. Sorry about that.
> > >
> > > Oleg
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> > > 
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> > > 
> > >
> > >
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

So is it a bug ? or a regular behaviour ?

thanks

On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 15:11 +0200, Philippe Mouawad wrote:
> > Hi Oleg,
> > Thanks for rapid answer.
> > Correct me if I am wrong but:
> > - URLENCODER is built from an or on UNRESERVED (which contains '_', '-',
> > '.', '*' and a-z, A-Z, 0-9.
> >
> > URLENCODER is passed as safechars in
> > private static String urlEncode(
> > final String content,
> > final Charset charset,
> > final BitSet safechars,
> > final boolean blankAsPlus)
> >
> >
> > @ is not part of the chars, so you end up in this part of algorithms
> right
> > ?:
> > } else {
> > buf.append("%");
> > final char hex1 =
> > Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
> > final char hex2 =
> > Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
> > buf.append(hex1);
> > buf.append(hex2);
> > }
> >
> > And thus it gets URL encoded no ?
> >
>
> Yes, I was mistaken. Sorry about that.
>
> Oleg
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

Hi Oleg,
Thanks for rapid answer.
Correct me if I am wrong but:
- URLENCODER is built from an or on UNRESERVED (which contains '_', '-',
'.', '*' and a-z, A-Z, 0-9.

URLENCODER is passed as safechars in
private static String urlEncode(
final String content,
final Charset charset,
final BitSet safechars,
final boolean blankAsPlus)


@ is not part of the chars, so you end up in this part of algorithms right
?:
} else {
buf.append("%");
final char hex1 =
Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, RADIX));
final char hex2 =
Character.toUpperCase(Character.forDigit(b & 0xF, RADIX));
buf.append(hex1);
buf.append(hex2);
}

And thus it gets URL encoded no ?

Thanks

On Sun, Sep 18, 2016 at 2:37 PM, Oleg Kalnichevski  wrote:

> On Sun, 2016-09-18 at 14:08 +0200, Philippe Mouawad wrote:
> > On Sunday, September 18, 2016, Oleg Kalnichevski 
> wrote:
> >
> > > On Sat, 2016-09-17 at 15:55 +0200, Philippe Mouawad wrote:
> > > > Hello,
> > > > We have a bug report at JMeter :
> > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
> > > >
> > > > Where  a user post a form with a parameter having this value
> > > > 'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'
> > > >
> > > > It appears that the '@' character is encoded.
> > > >
> > > > The form is submitted using application/x-www-form-urlencoded
> > > >
> > > > As per rfc:
> > > > > then reserved characters are escaped as described in [RFC1738]
> > > > <https://www.w3.org/TR/html401/references.html#ref-RFC1738>, section
> > > 2.2:
> > > >
> > > >
> > > > > The characters ";"  "/", "?", ":", "@", "=" and "&" are the
> characters
> > > > which may be reserved for special meaning within a scheme. No other
> > > > characters may be reserved within a scheme.
> > > >
> > > > So @ is reserved and as such HttpClient encodes it.
> > > >
> > > > But it is not clear for me if @ is reserved when place in URI or also
> > > > reserved when being part of a form parameter value.
> > > >
> > > > In JMeter code, we use UrlEncodedFormEntity and I check that when
> > > parameter
> > > > is passed , its value has still @ unencoded.
> > > >
> > >
> > > Why do you think it should be encoded?
> >
> >
> > I don't think it should but it is by HtTpClient class.
> > Maybe my last sentence was confusing, I recap, debugging the call, I see
> @
> > passed unencoded to httpclient method which encodes it.
> >
> >
>
> But it should not
>
> https://github.com/apache/httpclient/blob/4.5.x/
> httpclient/src/main/java/org/apache/http/client/utils/
> URLEncodedUtils.java#L654
>
> @ is not in the set of characters that need encoding
>
> https://github.com/apache/httpclient/blob/4.5.x/
> httpclient/src/main/java/org/apache/http/client/utils/
> URLEncodedUtils.java#L454https://github.com/apache/httpclient/blob/4.5.x/
> httpclient/src/main/java/org/apache/http/client/utils/
> URLEncodedUtils.java#L457
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

On Sunday, September 18, 2016, Oleg Kalnichevski  wrote:

> On Sat, 2016-09-17 at 15:55 +0200, Philippe Mouawad wrote:
> > Hello,
> > We have a bug report at JMeter :
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=60120
> >
> > Where  a user post a form with a parameter having this value
> > 'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'
> >
> > It appears that the '@' character is encoded.
> >
> > The form is submitted using application/x-www-form-urlencoded
> >
> > As per rfc:
> > > then reserved characters are escaped as described in [RFC1738]
> > <https://www.w3.org/TR/html401/references.html#ref-RFC1738>, section
> 2.2:
> >
> >
> > > The characters ";"  "/", "?", ":", "@", "=" and "&" are the characters
> > which may be reserved for special meaning within a scheme. No other
> > characters may be reserved within a scheme.
> >
> > So @ is reserved and as such HttpClient encodes it.
> >
> > But it is not clear for me if @ is reserved when place in URI or also
> > reserved when being part of a form parameter value.
> >
> > In JMeter code, we use UrlEncodedFormEntity and I check that when
> parameter
> > is passed , its value has still @ unencoded.
> >
>
> Why do you think it should be encoded?


I don't think it should but it is by HtTpClient class.
Maybe my last sentence was confusing, I recap, debugging the call, I see @
passed unencoded to httpclient method which encodes it.


>
> Oleg
>
> > Thanks for clarification.
> > Regards
> > Philippe M.
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

UrlEncodedFormEntity and parameter value encoding

[Philippe Mouawad]

Hello,
We have a bug report at JMeter :
https://bz.apache.org/bugzilla/show_bug.cgi?id=60120

Where  a user post a form with a parameter having this value
'IqGo6EM1JEVZ+MSRJqUSo@qhjVMSFBTs'

It appears that the '@' character is encoded.

The form is submitted using application/x-www-form-urlencoded

As per rfc:
> then reserved characters are escaped as described in [RFC1738]
, section 2.2:


> The characters ";"  "/", "?", ":", "@", "=" and "&" are the characters
which may be reserved for special meaning within a scheme. No other
characters may be reserved within a scheme.

So @ is reserved and as such HttpClient encodes it.

But it is not clear for me if @ is reserved when place in URI or also
reserved when being part of a form parameter value.

In JMeter code, we use UrlEncodedFormEntity and I check that when parameter
is passed , its value has still @ unencoded.

Thanks for clarification.
Regards
Philippe M.

Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0

[Philippe Mouawad]

Hi,
Because during load testing you want:
- to simulate browser behaviour, in a lot of case compression will be
enabled
- user will want to check server returns compressed response and also have
information about response sizes compressed which is the real traffic
taking place
- but then user will want to check data in the responses using assertion,
to do that we need responses to be uncompressed

Regards

On Sunday, May 1, 2016, Oleg Kalnichevski  wrote:

> On Sun, 2016-05-01 at 17:22 +0200, Philippe Mouawad wrote:
> > Hi Oleg,
> > I understand, but in our particular case users want to have information
> > about original response headers.
> >
>
> Why do not just disable content decompression if it is not needed?
>
> Oleg
>
> > Does this way of implementing it look ok to you:
> >
> >- https://bz.apache.org/bugzilla/attachment.cgi?id=33817&action=diff
> >
> > Or can it break something in HttpClient ?
> >
> > Thanks
> > Regards
> >
> > On Sun, May 1, 2016 at 5:18 PM, Oleg Kalnichevski  > wrote:
> >
> > > On Sun, 2016-05-01 at 16:08 +0200, Philippe Mouawad wrote:
> > > > Hello,
> > > > We have a regression report in JMeter 3.0 due to what seems to be a
> new
> > > > behaviour of HttpClient 4.5.2, introduced  on Feb 25, 2014 by:
> > > >
> > > >-
> > > >
> > >
> https://github.com/apache/httpclient/commit/5d11a3e751fe0c02a7a4539d3436b06e0be35876#diff-c54e3439558bee75dd7e2953280a7e08
> > > >
> > > >
> > > > As per following code:
> > > >
> > > > -
> > >
> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/protocol/ResponseContentEncoding.java#L142
> > > >
> > > >
> > > > When uncompressing HttpClient removes 3 headers:
> > > > - Content-Length
> > > > - Content-Encoding
> > > > - Content-MD5
> > > >
> > >
> > > This behavior was introduced in 4.2 (4 years ago). See HTTPCLIENT-1164.
> > > https://issues.apache.org/jira/browse/HTTPCLIENT-1164
> > >
> > > > So in JMeter 3.0, we lose these 3 headers compared to 2.13:
> > > > - https://bz.apache.org/bugzilla/show_bug.cgi?id=59401
> > > >
> > > > Is there a reason for removing them ?
> > > >
> > >
> > > Automatic decompression invalidates these headers. Decompressed content
> > > stream no longer has the same length, encoding and MD5 checksum as
> > > declared in the original response message.
> > >
> > > Oleg
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> > >
> > >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0

[Philippe Mouawad]

Hi Oleg,
I understand, but in our particular case users want to have information
about original response headers.

Does this way of implementing it look ok to you:

   - https://bz.apache.org/bugzilla/attachment.cgi?id=33817&action=diff

Or can it break something in HttpClient ?

Thanks
Regards

On Sun, May 1, 2016 at 5:18 PM, Oleg Kalnichevski  wrote:

> On Sun, 2016-05-01 at 16:08 +0200, Philippe Mouawad wrote:
> > Hello,
> > We have a regression report in JMeter 3.0 due to what seems to be a new
> > behaviour of HttpClient 4.5.2, introduced  on Feb 25, 2014 by:
> >
> >-
> >
> https://github.com/apache/httpclient/commit/5d11a3e751fe0c02a7a4539d3436b06e0be35876#diff-c54e3439558bee75dd7e2953280a7e08
> >
> >
> > As per following code:
> >
> > -
> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/protocol/ResponseContentEncoding.java#L142
> >
> >
> > When uncompressing HttpClient removes 3 headers:
> > - Content-Length
> > - Content-Encoding
> > - Content-MD5
> >
>
> This behavior was introduced in 4.2 (4 years ago). See HTTPCLIENT-1164.
> https://issues.apache.org/jira/browse/HTTPCLIENT-1164
>
> > So in JMeter 3.0, we lose these 3 headers compared to 2.13:
> > - https://bz.apache.org/bugzilla/show_bug.cgi?id=59401
> >
> > Is there a reason for removing them ?
> >
>
> Automatic decompression invalidates these headers. Decompressed content
> stream no longer has the same length, encoding and MD5 checksum as
> declared in the original response message.
>
> Oleg
>
>
> -----
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

ResponseContentEncoding behaviour in HttpClient 4.5.2 and 5.0

[Philippe Mouawad]

Hello,
We have a regression report in JMeter 3.0 due to what seems to be a new
behaviour of HttpClient 4.5.2, introduced  on Feb 25, 2014 by:

   -
   
https://github.com/apache/httpclient/commit/5d11a3e751fe0c02a7a4539d3436b06e0be35876#diff-c54e3439558bee75dd7e2953280a7e08


As per following code:

- 
https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/protocol/ResponseContentEncoding.java#L142


When uncompressing HttpClient removes 3 headers:
- Content-Length
- Content-Encoding
- Content-MD5

So in JMeter 3.0, we lose these 3 headers compared to 2.13:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=59401

Is there a reason for removing them ?

What are our options to fix it ?
1/ Register a ResponseInterceptor before it that extracts headers ?

2/ Override process method and do this:

private static final HttpResponseInterceptor RESPONSE_CONTENT_ENCODING
= new ResponseContentEncoding() {
@Override
public void process(
final HttpResponse response,
final HttpContext context) throws HttpException,
IOException {
List headersToRestore = new ArrayList<>(3);

headersToRestore.addAll(Arrays.asList(response.getHeaders("Content-Length")));

headersToRestore.addAll(Arrays.asList(response.getHeaders("Content-Encoding")));

headersToRestore.addAll(Arrays.asList(response.getHeaders("Content-MD5")));
super.process(response, context);
for (Header headerToRestore : headersToRestore) {
response.addHeader(headerToRestore);
}
}
};

3/ Submit a patch to make this removal optional  ? But this would delay a
lot our Release which was in RC3.

Thanks in advance for your help
Regards
Philippe M.


-- 
Cordialement.
Philippe Mouawad.

Re: Question about PoolingHttpClientConnectionManager#timeToLive

[Philippe Mouawad]

Hello,
Done https://issues.apache.org/jira/browse/HTTPCLIENT-1730

Regards

On Wed, Mar 9, 2016 at 1:10 PM, Oleg Kalnichevski  wrote:

> On Wed, 2016-03-09 at 13:07 +0100, Philippe Mouawad wrote:
> > Hi Oleg,
> > Thanks for clarification.
> > Regards
> >
> > On Wed, Mar 9, 2016 at 10:40 AM, Oleg Kalnichevski 
> wrote:
> >
> > > On Wed, 2016-03-09 at 08:40 +0100, Philippe Mouawad wrote:
> > > > Hello,
> > > > I would like a clarification on the
> > > > PoolingHttpClientConnectionManager#timeToLive that is used to
> construct
> > > the
> > > > PoolingHttpClientConnectionManager.
> > > >
> > > > In my understanding this value should not exceed the Keep Alive
> timeout
> > > > sent by a server.
> > > > Am I right or am I misunderstanding it ?
> > > >
> > >
> > > TTL represent an absolute value. No matter what the connection will not
> > > be re-used beyond its TTL. Keep-alive value is relative and gets
> updated
> > > every time connection is re-used.
> > >
> >
> > Do you want me to open a JIRA  +PR to add this to documentation ?
> >
>
> Sure. Please do so.
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Question about PoolingHttpClientConnectionManager#timeToLive

[Philippe Mouawad]

Hi Oleg,
Thanks for clarification.
Regards

On Wed, Mar 9, 2016 at 10:40 AM, Oleg Kalnichevski  wrote:

> On Wed, 2016-03-09 at 08:40 +0100, Philippe Mouawad wrote:
> > Hello,
> > I would like a clarification on the
> > PoolingHttpClientConnectionManager#timeToLive that is used to construct
> the
> > PoolingHttpClientConnectionManager.
> >
> > In my understanding this value should not exceed the Keep Alive timeout
> > sent by a server.
> > Am I right or am I misunderstanding it ?
> >
>
> TTL represent an absolute value. No matter what the connection will not
> be re-used beyond its TTL. Keep-alive value is relative and gets updated
> every time connection is re-used.
>

Do you want me to open a JIRA  +PR to add this to documentation ?

>
> > I think it should be better documented
> >
> >
> > Also another question about the call of this in the constructor:
> > this.pool.setValidateAfterInactivity(2000);
> >
> > Why isn't this value exposed to configuration ?
> > Am I wrong to think that it should be < Time to live in millis ?
> >
>
> No you are not. If the stale check time is greater than TTL it will
> simply have no effect.
>

Ok. clear

>
> Oleg
>
>
> -----
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Question about PoolingHttpClientConnectionManager#timeToLive

[Philippe Mouawad]

Hello,
I would like a clarification on the
PoolingHttpClientConnectionManager#timeToLive that is used to construct the
PoolingHttpClientConnectionManager.

In my understanding this value should not exceed the Keep Alive timeout
sent by a server.
Am I right or am I misunderstanding it ?

I think it should be better documented


Also another question about the call of this in the constructor:
this.pool.setValidateAfterInactivity(2000);

Why isn't this value exposed to configuration ?
Am I wrong to think that it should be < Time to live in millis ?

Take the following case:
- Server returns a keep alive of 1500 ms
- I suppose that validation will always fail and that between 1500 and 2000
ms invalid connections will be returned.

Thanks for clarifications

Regards
Philippe

Re: HttpClient 4.5.2 and Server Name Indication

[Philippe Mouawad]

Hi,
Have a look at this:
https://issues.apache.org/jira/browse/HTTPCLIENT-1119
You will see concerned classes, see:
https://github.com/apache/httpclient/commit/92b7e8cd971868505d0f22ee5cfc12a68ee91b80#diff-4f1f0cfa92ca97f7ee68436780ce874c


See Oleg's commit few minutes on deprecated classes:
http://svn.apache.org/viewvc?view=revision&revision=1733362

Regards

On Wed, Mar 2, 2016 at 9:51 PM, Oleg Kalnichevski  wrote:

> On Wed, 2016-03-02 at 15:48 -0500, Sam Wilson wrote:
> > On 3/2/16 3:41 PM, Oleg Kalnichevski wrote:
> > > On Wed, 2016-03-02 at 12:37 -0500, Sam Wilson wrote:
> > >>
> > >> Is there anything else I need to do to enable SNI?
> > >>
> > >
> > > No, there is not. Just make sure you are not using deprecated
> > > functionality.
> > >
> >
> > I'm sorry, are you saying that I am using deprecated functionality for
> > sure, or that I might be and should look for it. In either case, is
> > there something specific I should be looking for?
>
> It is merely a guess. Are you seeing any deprecation warnings related to
> HttpClient code when compiling your application?
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: About SNI support in HC4.5

[Philippe Mouawad]

For info,
fix done in JMeter based on the first patch attached to Httpclient issue
that by reflection sets the host on the java socket.

Regards

On Wednesday, December 30, 2015, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Ok, I understand , thanks Oleg.
> I was just thinking that if you had the fix in new layers, it would maybe
> be easy to fix it in deprecated ones. But I agree it might be loss of time
> on your side.
>
> On our side, as migration to 4.5.2 is not that easy and will surely take
> time, it would have been helpful.
>
> Regards
> Philippe
>
> On Wed, Dec 30, 2015 at 10:43 AM, Oleg Kalnichevski  > wrote:
>
>> On Tue, 2015-12-29 at 09:22 +0100, Philippe Mouawad wrote:
>> > Hello Oleg,
>> > Thanks for answer.
>> > Could you elaborate a bit more on your answer ?
>> >
>> > Also, is there a chance that you fix the issue also in deprecated code
>> of
>> > httpclient (org.apache.http.conn.ssl.SSLSocketFactory) or is it too
>> complex
>> > ?
>> >
>>
>> I personally see no point in fixing non-critical bugs in deprecated
>> code. This time can be better spent elsewhere. However I can commit a
>> fix though if contributed.
>>
>> Oleg
>>
>>
>> > Thanks
>> >
>> > On Wednesday, December 23, 2015, Oleg Kalnichevski > > wrote:
>> >
>> > > On Wed, 2015-12-23 at 14:30 +0100, Philippe Mouawad wrote:
>> > > > Hi,
>> > > > Any answer on the 1/ question ?
>> > > > Thanks
>> > > > Regards
>> > > >
>> > > > On Tue, Dec 22, 2015 at 2:39 PM, Philippe Mouawad <
>> > > > philippe.moua...@gmail.com
>> 
>> > wrote:
>> > > >
>> > > > > Hi,
>> > > > > With further investigation, I answered to some of my questions.
>> > > > >
>> > > > > Regards
>> > > > >
>> > > > > On Mon, Dec 21, 2015 at 6:52 PM, Philippe Mouawad <
>> > > > > philippe.moua...@gmail.com
>> 
>> > wrote:
>> > > > >
>> > > > >> Hello,
>> > > > >> Looking at:
>> > > > >>
>> > > > >>- https://issues.apache.org/jira/browse/HTTPCLIENT-1119
>> > > > >>
>> > > > >>
>> > > > >> 1/ It is not clear for me how the fix works if commit
>> association is
>> > > > >> correct:
>> > > > >>
>> > > > >>-
>> > > https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1544769
>> > > > >>
>> > > > >> Is the fix about replacing:
>> > > > >>
>> > > > >> final SSLSocket sock = (SSLSocket)
>> this.socketfactory.createSocket();
>> > > > >>
>> > > > >> with :
>> > > > >> SocketFactory.getDefault().createSocket();
>> > >
>> > > Pretty much. Please note though that the use of a plain socket instead
>> > > of a fully initialized SSL socket causes a different execution path in
>> > > #connectSocket method.
>> > >
>> > > Oleg
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Requirement in terms of Metrics : Latency

[Philippe Mouawad]

Thanks Oleg

On Thursday, January 21, 2016, Oleg Kalnichevski  wrote:

> On Thu, 2016-01-21 at 13:44 +0100, Philippe Mouawad wrote:
> > Hello Oleg,
> > Thanks for answer.
> > For request it should be ok ,but I am not sure for response as I need
> time
> > to first byte.
> > I think I need something just after:
> >
> > > response = conn.receiveResponseHeader();
> >
>
> Blocking I/O connections do not actually read message body. They merely
> attach the stream to the message entity (this is the reason why one
> needs to explicitly release connections in the classic I/O mode).
>
> So, #execute method execution time will give you the time between
> transmission of the entire request message and receipt of the response
> head, which is most cases is as good as the time until first response
> byte.
>
> Oleg
>
>
>
> > Regards
> >
> >
> >
> >
> > On Mon, Jan 18, 2016 at 10:06 AM, Oleg Kalnichevski  >
> > wrote:
> >
> > > On Sun, 2016-01-17 at 13:32 -0800, Gary Gregory wrote:
> > > > I'll let Oleg opine on the right way...
> > > >
> > > > Gary
> > > > On Jan 17, 2016 1:28 PM, "Philippe Mouawad" <
> philippe.moua...@gmail.com >
> > > > wrote:
> > > >
> > > > > Hi Gary,
> > > > > First I just wanted some confirmation that it's the right way.
> > > > > Then I will see if I can provide a patch.
> > > > >
> > > > > Regards
> > > > >
> > > > > On Sunday, January 17, 2016, Gary Gregory  >
> > > wrote:
> > > > >
> > > > > > Hi Philippe,
> > > > > >
> > > > > > If you want to speed up the process, I'd recommend you provide a
> > > patch on
> > > > > > top of trunk.
> > > > > >
> > > > > > 2c,
> > > > > > Gary
> > > > > >
> > > > > > On Sun, Jan 17, 2016 at 5:33 AM, Philippe Mouawad <
> > > pmoua...@apache.org 
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > Any feedback on this question ?
> > > > > > > Thanks
> > > > > > >
> > > > > > > On Wed, Jan 13, 2016 at 10:48 PM, Philippe Mouawad <
> > > > > pmoua...@apache.org 
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > We have a requirement in JMeter to compute latency in the
> most
> > > > > accurate
> > > > > > > > way:
> > > > > > > >
> > > > > > > >- latency being  the time between the start of the request
> > > send
> > > > > and
> > > > > > > >the first byte receival.
> > > > > > > >
> > > > > > > > Currently it appears there is an interface called:
> > > > > > > >
> > > > > > > >- org.apache.http.HttpConnectionMetrics
> > > > > > > >
> > > > > > > > implemented by :
> > > > > > > >
> > > > > > > >- org.apache.http.impl.HttpConnectionMetricsImpl
> > > > > > > >
> > > > > > > > It would be nice to enhance to compute this latency within
> > > > > > > > HTTPCore/HTTPClient.
> > > > > > > >
> > > > > > > > Or maybe this already exists.
> > > > > > > >
> > >
> > > What you probably want is to capture the time spent in
> > > HttpRequestExecutor#execute.
> > >
> > >
> > >
> http://hc.apache.org/httpcomponents-core-4.4.x/httpcore/xref/org/apache/http/protocol/HttpRequestExecutor.html#114
> > >
> > > You can do so by extending the class and decorating the #execute
> method.
> > >
> > > Oleg
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> > >
> > >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: CookieSpecs : Which one to choose ?

[Philippe Mouawad]

Hello,
Any feedback ?

Thanks for your time and congrats for the 4.5.2.

Regards

On Friday, February 26, 2016, Philippe Mouawad 
wrote:

> Hello,
> I am not sure what should be the default Cookie Policy for JMeter 3.0
> with  HC4.5.2
>
> As per HttpClient doc:
>
> https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/config/CookieSpecs.java
>
> Standard seems the best:
>
>- The RFC 6265 compliant policy (interoprability profile).
>
> But default :
>
>- The default policy. This policy provides a higher degree of
>compatibility with common cookie management of popular HTTP agents for
>non-standard (Netscape style) cookies.
>
>
> Do browsers accept the 2 , in this case should we create a CookieSpec
> implementation that delegate to DefaultCookieSpec and RFC6265LaxSpec ?
>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

CookieSpecs : Which one to choose ?

[Philippe Mouawad]

Hello,
I am not sure what should be the default Cookie Policy for JMeter 3.0 with
HC4.5.2

As per HttpClient doc:
https://github.com/apache/httpclient/blob/4.5.x/httpclient/src/main/java/org/apache/http/client/config/CookieSpecs.java

Standard seems the best:

   - The RFC 6265 compliant policy (interoprability profile).

But default :

   - The default policy. This policy provides a higher degree of
   compatibility with common cookie management of popular HTTP agents for
   non-standard (Netscape style) cookies.


Do browsers accept the 2 , in this case should we create a CookieSpec
implementation that delegate to DefaultCookieSpec and RFC6265LaxSpec ?




-- 
Cordialement.
Philippe Mouawad.

Re: HttpClient SSL Connection Issue

[Philippe Mouawad]

Hi Oleg,
I was wrong as per my N-1 mail .



On Mon, Feb 22, 2016 at 9:13 PM, Oleg Kalnichevski  wrote:

> On Mon, 2016-02-22 at 21:08 +0100, Philippe Mouawad wrote:
> > Hi Oleg,
> > I tried the URL using JMeter and HttpClient 4.5.2 it fails.
> >
> > I don't see big differences when comparing ssl logs:
> > Thread Group 1-1, handling exception: java.net.SocketException:
> Connection
> > reset
> > %% Invalidated:  [Session-4, TLS_RSA_WITH_AES_128_CBC_SHA]
> > Thread Group 1-1, SEND TLSv1 ALERT:  fatal, description =
> unexpected_message
> > Padded plaintext before ENCRYPTION:  len = 32
> > : 02 0A 75 43 41 2D 66 FE   B7 2F 45 02 3C 21 E7 67  ..uCA-f../E. > 0010: 6B 9C 21 52 18 37 09 09   09 09 09 09 09 09 09 09  k.!R.7..
> > Thread Group 1-1, WRITE: TLSv1 Alert, length = 32
> > Thread Group 1-1, Exception sending alert: java.net.SocketException:
> Broken
> > pipe
> > Thread Group 1-1, called closeSocket()
> > Thread Group 1-1, called close()
> > Thread Group 1-1, called closeInternal(true)
> >
> >
> > It seems like a bug in HttpClient no ?
> >
>
> How exactly can this be a bug in HttpClient?
>
> Oleg
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: HttpClient SSL Connection Issue

[Philippe Mouawad]

Good catch @Tim !


Indeed Java:
Padded plaintext before ENCRYPTION:  len = 176
: 47 45 54 20 2F 20 48 54   54 50 2F 31 2E 31 0D 0A  GET / HTTP/1.1..
0010: 43 6F 6E 6E 65 63 74 69   6F 6E 3A 20 6B 65 65 70  Connection: keep
0020: 2D 61 6C 69 76 65 0D 0A   55 73 65 72 2D 41 67 65  -alive..User-Age
0030: 6E 74 3A 20 4A 61 76 61   2F 31 2E 38 2E 30 5F 34  nt: Java/1.8.0_4
0040: 35 0D 0A 48 6F 73 74 3A   20 73 6F 2E 6E 31 31 2E  5..Host: so.n11.
0050: 63 6F 6D 0D 0A 41 63 63   65 70 74 3A 20 74 65 78  com..Accept: tex
0060: 74 2F 68 74 6D 6C 2C 20   69 6D 61 67 65 2F 67 69  t/html, image/gi
0070: 66 2C 20 69 6D 61 67 65   2F 6A 70 65 67 2C 20 2A  f, image/jpeg, *
0080: 3B 20 71 3D 2E 32 2C 20   2A 2F 2A 3B 20 71 3D 2E  ; q=.2, */*; q=.
0090: 32 0D 0A 0D 0A 32 8B 87   7A BA 17 82 81 CD BB C5  22..z...
00A0: F8 E3 E0 C4 B1 53 A6 09   63 06 06 06 06 06 06 06  .S..c...
Thread Group 1-1, WRITE: TLSv1 Application Data, length = 176


HttpClient:
Padded plaintext before ENCRYPTION:  len = 144
: 47 45 54 20 2F 20 48 54   54 50 2F 31 2E 31 0D 0A  GET / HTTP/1.1..
0010: 43 6F 6E 6E 65 63 74 69   6F 6E 3A 20 6B 65 65 70  Connection: keep
0020: 2D 61 6C 69 76 65 0D 0A   48 6F 73 74 3A 20 73 6F  -alive..Host: so
0030: 2E 6E 31 31 2E 63 6F 6D   0D 0A 55 73 65 72 2D 41  .n11.com..User-A
0040: 67 65 6E 74 3A 20 41 70   61 63 68 65 2D 48 74 74  gent: Apache-Htt
0050: 70 43 6C 69 65 6E 74 2F   34 2E 35 2E 32 2D 53 4E  pClient/4.5.2-SN
0060: 41 50 53 48 4F 54 20 28   4A 61 76 61 2F 31 2E 38  APSHOT (Java/1.8
0070: 2E 30 5F 34 35 29 0D 0A   0D 0A 68 D5 4F F4 33 6B  .0_45)h.O.3k
0080: 1B 37 6F 3B CC 01 D2 D8   7F 95 02 FB 58 3A 01 01  .7o;X:..
Thread Group 1-1, WRITE: TLSv1 Application Data, length = 144


Learnt something today , thanks !

On Mon, Feb 22, 2016 at 9:03 PM, Tim Jacomb [DATACOM] 
wrote:

> Try adding an Accept Header, the server you are contacting appears to
> reject all requests without one
>
> httpGet.addHeader("Accept",
> "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8");
>
> Tim
> 
> From: Murat Balkan 
> Sent: Tuesday, 23 February 2016 8:38 a.m.
> To: HttpClient User Discussion
> Subject: Re: HttpClient SSL Connection Issue
>
> Hi, Please find it below: The version does not matter. Whatever version I
> tried failed. I even installed Java 8 to test. My current versions in the
> built path are: httpclient4.5.1,httpcore4.4.3,httpmime 4.5.1, jna 4.1.0,
> jna-platform4.1.0,httpclient-cache4.5.1
>
> SSLContext sslContext = SSLContexts.createDefault();
> SSLConnectionSocketFactory sslConnectionFactory = new
> SSLConnectionSocketFactory(sslContext,NoopHostnameVerifier.INSTANCE);
> Registry socketFactoryRegistry =
> RegistryBuilder.create()
> .register("http", PlainConnectionSocketFactory.getSocketFactory())
> .register("https", sslConnectionFactory)
> .build();
> PoolingHttpClientConnectionManager cm = new
> PoolingHttpClientConnectionManager(socketFactoryRegistry);
> cm.setDefaultMaxPerRoute(1);
> CloseableHttpClient httpClient = HttpClientBuilder.create()
> .disableContentCompression()
> .disableAutomaticRetries()
> .setUserAgent("User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0)
> Gecko/20100101 Firefox/44.0")
> .build();
> HttpGet httpGet = new HttpGet("https://so.n11.com";);
> httpClient.execute(httpGet);
> System.out.println("I can never reach this point");
>
> On Mon, Feb 22, 2016 at 2:33 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
> > hi,
> > Can you show your httpclient code and mention which versions you used for
> > httpcore and httpclient and java exact version
> >
> > thx
> >
> > On Monday, February 22, 2016, Murat Balkan  wrote:
> >
> > > I tried the following with URL class this time:
> > >
> > > URL my_url = new URL("https://so.n11.com";);
> > > BufferedReader br = new BufferedReader(new
> > > InputStreamReader(my_url.openStream()));
> > > String strTemp = "";
> > > while(null != (strTemp = br.readLine())){
> > > System.out.println(strTemp);
> > > }
> > >
> > > Even this works. So far URL, HttpURLConnection and Browsers are able to
> > > fetch the page. Apache HttpClient cannot.
> > > I also tried Fluent from the same package. It fails too.
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Feb 22, 2016 at 12:40 PM, Oleg Kalnichevski  > > >
> > > wrote:
> > >
> > > > On Mon, 2016-02-22 at 11:27 -0500, Murat Balkan wrote:
> > > > > Can you please suggest 

Re: HttpClient SSL Connection Issue

[Philippe Mouawad]

Hi Oleg,
I tried the URL using JMeter and HttpClient 4.5.2 it fails.

I don't see big differences when comparing ssl logs:
Thread Group 1-1, handling exception: java.net.SocketException: Connection
reset
%% Invalidated:  [Session-4, TLS_RSA_WITH_AES_128_CBC_SHA]
Thread Group 1-1, SEND TLSv1 ALERT:  fatal, description = unexpected_message
Padded plaintext before ENCRYPTION:  len = 32
: 02 0A 75 43 41 2D 66 FE   B7 2F 45 02 3C 21 E7 67  ..uCA-f../E. wrote:

> Hi, Please find it below: The version does not matter. Whatever version I
> tried failed. I even installed Java 8 to test. My current versions in the
> built path are: httpclient4.5.1,httpcore4.4.3,httpmime 4.5.1, jna 4.1.0,
> jna-platform4.1.0,httpclient-cache4.5.1
>
> SSLContext sslContext = SSLContexts.createDefault();
> SSLConnectionSocketFactory sslConnectionFactory = new
> SSLConnectionSocketFactory(sslContext,NoopHostnameVerifier.INSTANCE);
> Registry socketFactoryRegistry =
> RegistryBuilder.create()
> .register("http", PlainConnectionSocketFactory.getSocketFactory())
> .register("https", sslConnectionFactory)
> .build();
> PoolingHttpClientConnectionManager cm = new
> PoolingHttpClientConnectionManager(socketFactoryRegistry);
> cm.setDefaultMaxPerRoute(1);
> CloseableHttpClient httpClient = HttpClientBuilder.create()
> .disableContentCompression()
> .disableAutomaticRetries()
> .setUserAgent("User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0)
> Gecko/20100101 Firefox/44.0")
> .build();
> HttpGet httpGet = new HttpGet("https://so.n11.com";);
> httpClient.execute(httpGet);
> System.out.println("I can never reach this point");
>
> On Mon, Feb 22, 2016 at 2:33 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
> > hi,
> > Can you show your httpclient code and mention which versions you used for
> > httpcore and httpclient and java exact version
> >
> > thx
> >
> > On Monday, February 22, 2016, Murat Balkan  wrote:
> >
> > > I tried the following with URL class this time:
> > >
> > > URL my_url = new URL("https://so.n11.com";);
> > > BufferedReader br = new BufferedReader(new
> > > InputStreamReader(my_url.openStream()));
> > > String strTemp = "";
> > > while(null != (strTemp = br.readLine())){
> > > System.out.println(strTemp);
> > > }
> > >
> > > Even this works. So far URL, HttpURLConnection and Browsers are able to
> > > fetch the page. Apache HttpClient cannot.
> > > I also tried Fluent from the same package. It fails too.
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Feb 22, 2016 at 12:40 PM, Oleg Kalnichevski  > > >
> > > wrote:
> > >
> > > > On Mon, 2016-02-22 at 11:27 -0500, Murat Balkan wrote:
> > > > > Can you please suggest me how HttpClient can get the page like
> > > > > HttpUrlConnection? or Google Chrome?
> > > >
> > > > Capture a session between a browser or HttpUrlConnection using
> > Wireshark
> > > > or browser plugin of your choosing. Configure HttpClient to generate
> > > > identical messages. See what happens.
> > > >
> > > > > If I go to the site admin, wouldnt he say the site is totally
> > > reachable?
> > > > >
> > > >
> > > > The admin can say that Earth is flat for all I care, but their server
> > > > drops connections without sending back a status code like all well
> > > > behaved, spec complaint HTTP servers are supposed to do.
> > > >
> > > > Oleg
> > > >
> > > >
> > > >
> > > > > On Mon, Feb 22, 2016 at 11:22 AM, Oleg Kalnichevski <
> > ol...@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > On Mon, 2016-02-22 at 11:18 -0500, Murat Balkan wrote:
> > > > > > > Hi Oleg,
> > > > > > > I do not aggree, other Http libraries does not have this
> problem.
> > > As
> > > > I
> > > > > > said
> > > > > > > HttpUrlConnection gets the page, all types of browsers can get
> > the
> > > > page.
> > > > > > It
> > > > > > > is clear that this is an error that is related with the Apache
> > > > Client.
> > > > > > > Thnaks
> > > > > > > Murat
> > > > > >
> > > > > > You are ve

Re: HttpClient SSL Connection Issue

[Philippe Mouawad]

anagedHttpClientConnection -
> > > > > > > http-outgoing-3: Close connection
> > > > > > > 2016/02/22 10:49:45:419 EST [DEBUG]
> > > > DefaultManagedHttpClientConnection -
> > > > > > > http-outgoing-3: Shutdown connection
> > > > > > > 2016/02/22 10:49:45:419 EST [DEBUG] MainClientExec - Connection
> > > > discarded
> > > > > > >
> > > > > >
> > > > > > The connection is dropped by the server due to an internal error
> of
> > > > some
> > > > > > sort. You need to take it up with the server admin.
> > > > > >
> > > > > > Oleg
> > > > > >
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail:
> httpclient-users-unsubscr...@hc.apache.org 
> > > > > > For additional commands, e-mail:
> > httpclient-users-h...@hc.apache.org 
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> > > >
> > > >
> > >
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> 
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> 
> >
> >
>
>
> --
> Murat Balkan
>


-- 
Cordialement.
Philippe Mouawad.

Re: httpClient.getConnectionManager() performance with HTTP only

[Philippe Mouawad]

Hello,
For information on a test plan with following configuration (15 threads, 5
minutes run) we make 138% more samples with 3.0 than with 2.13 thanks to
fixing of https://bz.apache.org/bugzilla/show_bug.cgi?id=58099.
The gain is due to the non init of SSL Context when only HTTP is used.
Maybe including this in HttpClient should be reconsidered.

Regards
Philippe

On Wed, Feb 17, 2016 at 7:47 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> I think I have fixed the issue in JMeter, I attached patch to:
> - https://bz.apache.org/bugzilla/show_bug.cgi?id=58099
>
> Reviews and feedback very welcome.
> Regards
>
> On Tue, Jan 5, 2016 at 3:05 PM, sebb  wrote:
>
>> On 22 December 2015 at 08:36, Oleg Kalnichevski  wrote:
>> > On Sun, 2015-12-20 at 22:44 +0100, Philippe Mouawad wrote:
>> >> Hi Oleg,
>> >> Back to this old subject and knowing that we must stick to 1
>> HttpClient per
>> >> thread (as per all the discussion that followed this).
>> >> Is there a plan to implement this lazy init of SSLContext in
>> HttpClient as
>> >> it used to be the case in HC3 ?
>> >>
>> >> For our project, it's a killer in terms of performance, and for other
>> use
>> >> cases, it appears kind of weird that an SSLContext is initialized even
>> for
>> >> a pure HTTP traffic.
>> >>
>> >
>> > Given that HttpClient instance should be initialized only once, eager
>> > initialization of the SSLContext looks reasonable to me.
>>
>> AFAICT there are lots of ways to configure the HttpClient instance by
>> using HttpClientBuilder or HttpClients.
>> So I don't understand why you say that the HttpClient instance should
>> only be initialised once.
>>
>> > One, of course, can make SSL initialization lazy by using a custom
>> > connection socket factory with SSLContext initialized on demand.
>> >
>> > Hope this helps
>> >
>> > Oleg
>> >
>> >> Thanks
>> >> Regards
>> >>
>> >>
>> >>
>> >> On Thu, May 15, 2014 at 10:39 AM, Oleg Kalnichevski 
>> >> wrote:
>> >>
>> >> > On Wed, 2014-05-14 at 19:46 +0100, sebb wrote:
>> >> > > On 14 May 2014 12:28, Oleg Kalnichevski  wrote:
>> >> >
>> >> > ...
>> >> >
>> >> > > >> Issue is not present in HTTPCLient 3.1
>> >> > > >
>> >> > > > Philippe
>> >> > > >
>> >> > > > If HttpClient is used correctly, this code should only be
>> executed only
>> >> > > > once. Why does JMeter create more than one instance of
>> HttpClient?
>> >> > >
>> >> > > We currently create an instance for each instance of different
>> proxy
>> >> > > settings and each protocol and each authority, because the client
>> is
>> >> > > created with these settings.
>> >> > >
>> >> > > This is also done for each thread.
>> >> > >
>> >> > > IIRC, this was necessary originally. We have not rewritten the code
>> >> > > yet to use all the latest features.
>> >> > >
>> >> >
>> >> > I see. For the time what you can do is to use a custom SSL socket
>> >> > factory that lazily initializes SSL context when requested for the
>> first
>> >> > time. This is exactly what HC 3.1 does. It will be somewhat slower
>> given
>> >> > that one would need to mutex to synchronize access to the
>> initialization
>> >> > code.
>> >> >
>> >> > Oleg
>> >> >
>> >> > > > Oleg
>> >> > > >
>> >> > >
>> >> > >
>> -
>> >> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
>> >> > > For additional commands, e-mail:
>> httpclient-users-h...@hc.apache.org
>> >> > >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: HttpClient 4.5.2 release preparations

[Philippe Mouawad]

Hello,
I tested 4.5.X branch, I reported an issue which Gary handled:

   - https://issues.apache.org/jira/browse/HTTPCLIENT-1665

The 3 bugs we are concerned about are fixed:

   - https://bz.apache.org/bugzilla/show_bug.cgi?id=58950
   - https://bz.apache.org/bugzilla/show_bug.cgi?id=58881
   - https://bz.apache.org/bugzilla/show_bug.cgi?id=58583


Maybe a bug in HttpClient should be created for
https://issues.apache.org/jira/browse/HTTPCORE-397 so that release notes
are complete:

   - http://svn.apache.org/viewvc?view=revision&revision=1722952


Looking at this file:

https://github.com/apache/httpclient/blob/04fb7e6d8e2aef7ae4465b26a931deffb9775450/RELEASE_NOTES.txt


It seems to me it is incomplete and should mention all those no ?:

https://issues.apache.org/jira/browse/HTTPCLIENT-1665?jql=project%20%3D%20HTTPCLIENT%20AND%20fixVersion%20%3D%204.5.2%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC


Anyway thanks at your team for the work.

Regards

Philippe



On Fri, Feb 19, 2016 at 7:50 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hi Oleg,
> Of course, we've been waiting for it for some time now so it will be with
> pleasure.
>
> Thanks for your work.
> Regards
>
>
> On Friday, February 19, 2016, Oleg Kalnichevski  wrote:
>
>> Hi Philippe
>>
>> I'll try to get around to starting HC 4.5.2 release process this
>> weekend. I would appreciate if you could test JMeter with the latest
>> snapshot of HC and let me know if everything works as expected.
>>
>> Cheers
>>
>> Oleg
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: httpClient.getConnectionManager() performance with HTTP only

[Philippe Mouawad]

Hello,
I think I have fixed the issue in JMeter, I attached patch to:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=58099

Reviews and feedback very welcome.
Regards

On Tue, Jan 5, 2016 at 3:05 PM, sebb  wrote:

> On 22 December 2015 at 08:36, Oleg Kalnichevski  wrote:
> > On Sun, 2015-12-20 at 22:44 +0100, Philippe Mouawad wrote:
> >> Hi Oleg,
> >> Back to this old subject and knowing that we must stick to 1 HttpClient
> per
> >> thread (as per all the discussion that followed this).
> >> Is there a plan to implement this lazy init of SSLContext in HttpClient
> as
> >> it used to be the case in HC3 ?
> >>
> >> For our project, it's a killer in terms of performance, and for other
> use
> >> cases, it appears kind of weird that an SSLContext is initialized even
> for
> >> a pure HTTP traffic.
> >>
> >
> > Given that HttpClient instance should be initialized only once, eager
> > initialization of the SSLContext looks reasonable to me.
>
> AFAICT there are lots of ways to configure the HttpClient instance by
> using HttpClientBuilder or HttpClients.
> So I don't understand why you say that the HttpClient instance should
> only be initialised once.
>
> > One, of course, can make SSL initialization lazy by using a custom
> > connection socket factory with SSLContext initialized on demand.
> >
> > Hope this helps
> >
> > Oleg
> >
> >> Thanks
> >> Regards
> >>
> >>
> >>
> >> On Thu, May 15, 2014 at 10:39 AM, Oleg Kalnichevski 
> >> wrote:
> >>
> >> > On Wed, 2014-05-14 at 19:46 +0100, sebb wrote:
> >> > > On 14 May 2014 12:28, Oleg Kalnichevski  wrote:
> >> >
> >> > ...
> >> >
> >> > > >> Issue is not present in HTTPCLient 3.1
> >> > > >
> >> > > > Philippe
> >> > > >
> >> > > > If HttpClient is used correctly, this code should only be
> executed only
> >> > > > once. Why does JMeter create more than one instance of HttpClient?
> >> > >
> >> > > We currently create an instance for each instance of different proxy
> >> > > settings and each protocol and each authority, because the client is
> >> > > created with these settings.
> >> > >
> >> > > This is also done for each thread.
> >> > >
> >> > > IIRC, this was necessary originally. We have not rewritten the code
> >> > > yet to use all the latest features.
> >> > >
> >> >
> >> > I see. For the time what you can do is to use a custom SSL socket
> >> > factory that lazily initializes SSL context when requested for the
> first
> >> > time. This is exactly what HC 3.1 does. It will be somewhat slower
> given
> >> > that one would need to mutex to synchronize access to the
> initialization
> >> > code.
> >> >
> >> > Oleg
> >> >
> >> > > > Oleg
> >> > > >
> >> > >
> >> > >
> -
> >> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> >> > > For additional commands, e-mail:
> httpclient-users-h...@hc.apache.org
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>



-- 
Cordialement.
Philippe Mouawad.

Re: Release a 4.5.2 ?

[Philippe Mouawad]

Hi Oleg,
Is there a procedure for RM ?
If I volunteered, I suppose I would need commiter rights which I don't
think I have.

Regards
Philippe

On Thu, Jan 21, 2016 at 2:28 PM, Oleg Kalnichevski  wrote:

> On Thu, 2016-01-21 at 13:42 +0100, Philippe Mouawad wrote:
> > Hi Oleg,
> > Any chance to release before ?
> > WIll it be begining or end of february ?
> > Thanks
> >
>
> I would say first half of February unless some one else wants to
> volunteer to RM this release.
>
> Oleg
>
>
> > On Thu, Jan 21, 2016 at 9:34 AM, Oleg Kalnichevski 
> wrote:
> >
> > > On Wed, 2016-01-20 at 21:44 +0100, Philippe Mouawad wrote:
> > > > Hi,
> > > > I would like to know when the release of 4.5.2 is planned ?
> > > >
> > > > Thanks
> > > > Regards
> > >
> > > No immediate plans. Likely in February.
> > >
> > > Oleg
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> > >
> > >
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Requirement in terms of Metrics : Latency

[Philippe Mouawad]

Hello Oleg,
Thanks for answer.
For request it should be ok ,but I am not sure for response as I need time
to first byte.
I think I need something just after:

> response = conn.receiveResponseHeader();

Regards




On Mon, Jan 18, 2016 at 10:06 AM, Oleg Kalnichevski 
wrote:

> On Sun, 2016-01-17 at 13:32 -0800, Gary Gregory wrote:
> > I'll let Oleg opine on the right way...
> >
> > Gary
> > On Jan 17, 2016 1:28 PM, "Philippe Mouawad" 
> > wrote:
> >
> > > Hi Gary,
> > > First I just wanted some confirmation that it's the right way.
> > > Then I will see if I can provide a patch.
> > >
> > > Regards
> > >
> > > On Sunday, January 17, 2016, Gary Gregory 
> wrote:
> > >
> > > > Hi Philippe,
> > > >
> > > > If you want to speed up the process, I'd recommend you provide a
> patch on
> > > > top of trunk.
> > > >
> > > > 2c,
> > > > Gary
> > > >
> > > > On Sun, Jan 17, 2016 at 5:33 AM, Philippe Mouawad <
> pmoua...@apache.org
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > > Any feedback on this question ?
> > > > > Thanks
> > > > >
> > > > > On Wed, Jan 13, 2016 at 10:48 PM, Philippe Mouawad <
> > > pmoua...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > We have a requirement in JMeter to compute latency in the most
> > > accurate
> > > > > > way:
> > > > > >
> > > > > >- latency being  the time between the start of the request
> send
> > > and
> > > > > >the first byte receival.
> > > > > >
> > > > > > Currently it appears there is an interface called:
> > > > > >
> > > > > >- org.apache.http.HttpConnectionMetrics
> > > > > >
> > > > > > implemented by :
> > > > > >
> > > > > >- org.apache.http.impl.HttpConnectionMetricsImpl
> > > > > >
> > > > > > It would be nice to enhance to compute this latency within
> > > > > > HTTPCore/HTTPClient.
> > > > > >
> > > > > > Or maybe this already exists.
> > > > > >
>
> What you probably want is to capture the time spent in
> HttpRequestExecutor#execute.
>
>
> http://hc.apache.org/httpcomponents-core-4.4.x/httpcore/xref/org/apache/http/protocol/HttpRequestExecutor.html#114
>
> You can do so by extending the class and decorating the #execute method.
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Release a 4.5.2 ?

[Philippe Mouawad]

Hi Oleg,
Any chance to release before ?
WIll it be begining or end of february ?
Thanks

On Thu, Jan 21, 2016 at 9:34 AM, Oleg Kalnichevski  wrote:

> On Wed, 2016-01-20 at 21:44 +0100, Philippe Mouawad wrote:
> > Hi,
> > I would like to know when the release of 4.5.2 is planned ?
> >
> > Thanks
> > Regards
>
> No immediate plans. Likely in February.
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Release a 4.5.2 ?

[Philippe Mouawad]

Hi,
I would like to know when the release of 4.5.2 is planned ?

Thanks
Regards

Re: Requirement in terms of Metrics : Latency

[Philippe Mouawad]

Hi Gary,
First I just wanted some confirmation that it's the right way.
Then I will see if I can provide a patch.

Regards

On Sunday, January 17, 2016, Gary Gregory  wrote:

> Hi Philippe,
>
> If you want to speed up the process, I'd recommend you provide a patch on
> top of trunk.
>
> 2c,
> Gary
>
> On Sun, Jan 17, 2016 at 5:33 AM, Philippe Mouawad  >
> wrote:
>
> > Hi,
> > Any feedback on this question ?
> > Thanks
> >
> > On Wed, Jan 13, 2016 at 10:48 PM, Philippe Mouawad  >
> > wrote:
> >
> > > Hello,
> > >
> > > We have a requirement in JMeter to compute latency in the most accurate
> > > way:
> > >
> > >- latency being  the time between the start of the request send and
> > >the first byte receival.
> > >
> > > Currently it appears there is an interface called:
> > >
> > >- org.apache.http.HttpConnectionMetrics
> > >
> > > implemented by :
> > >
> > >- org.apache.http.impl.HttpConnectionMetricsImpl
> > >
> > > It would be nice to enhance to compute this latency within
> > > HTTPCore/HTTPClient.
> > >
> > > Or maybe this already exists.
> > >
> > > I looked at some other way with HttpRequestInterceptor /
> > > HttpResponseInterceptor , but I don't think it's the correct place.
> > >
> > >
> > > Thanks
> > >
> > > Regards
> > >
> > > Philippe M.
> > >
> > > @philmdot
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com  | ggreg...@apache.org
> 
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


-- 
Cordialement.
Philippe Mouawad.

Re: Requirement in terms of Metrics : Latency

[Philippe Mouawad]

Hi,
Any feedback on this question ?
Thanks

On Wed, Jan 13, 2016 at 10:48 PM, Philippe Mouawad 
wrote:

> Hello,
>
> We have a requirement in JMeter to compute latency in the most accurate
> way:
>
>- latency being  the time between the start of the request send and
>the first byte receival.
>
> Currently it appears there is an interface called:
>
>- org.apache.http.HttpConnectionMetrics
>
> implemented by :
>
>- org.apache.http.impl.HttpConnectionMetricsImpl
>
> It would be nice to enhance to compute this latency within
> HTTPCore/HTTPClient.
>
> Or maybe this already exists.
>
> I looked at some other way with HttpRequestInterceptor /
> HttpResponseInterceptor , but I don't think it's the correct place.
>
>
> Thanks
>
> Regards
>
> Philippe M.
>
> @philmdot
>

Requirement in terms of Metrics : Latency

[Philippe Mouawad]

Hello,

We have a requirement in JMeter to compute latency in the most accurate way:

   - latency being  the time between the start of the request send and the
   first byte receival.

Currently it appears there is an interface called:

   - org.apache.http.HttpConnectionMetrics

implemented by :

   - org.apache.http.impl.HttpConnectionMetricsImpl

It would be nice to enhance to compute this latency within
HTTPCore/HTTPClient.

Or maybe this already exists.

I looked at some other way with HttpRequestInterceptor /
HttpResponseInterceptor , but I don't think it's the correct place.


Thanks

Regards

Philippe M.

@philmdot

Re: Connection:close header and HttpClient behaviour

[Philippe Mouawad]

Hi Oleg,
I think I understand why it was not integrated to 4.4.x branch, signature
of DefaultConnectionReuseStrategy#keepAlive did not contain request.

I have submitted a PR for 4.4.x:
https://github.com/apache/httpcore/pull/19

it works for our need 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


On Wed, Dec 30, 2015 at 3:01 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hi Oleg,
> Thanks for answer.
>
> Why is the fix not in 4.4.4 ? From commit date and release date of 4.4.4,
> I  would say it should have been no ?
>
> Bug from JIRA https://issues.apache.org/jira/browse/HTTPCORE-397, I see
> fixVersion is 5.0-alpha1 but piece of code is not in 4.4.4
>
>
> Thanks
>
> On Wed, Dec 30, 2015 at 10:53 AM, Oleg Kalnichevski 
> wrote:
>
>> On Tue, 2015-12-29 at 17:34 +0100, Philippe Mouawad wrote:
>> > Hello,
>> > We have a bug report in JMeter :
>> > https://bz.apache.org/bugzilla/show_bug.cgi?id=58583
>> >
>> > To summarize, setting "Connection: close" header in the requests does
>> not
>> > make HttpClient close the connection on the client side.
>> >
>> > It seems to be a violation of RFC 2616:
>> > http://tools.ietf.org/html/rfc2616#page-45
>> > http://tools.ietf.org/html/rfc2616#section-14.10
>> >
>> >
>> > And RFC7230:
>> > http://tools.ietf.org/html/rfc7230#section-6.1
>> >
>> >
>> > I am not sure what to think about this.
>> >
>>
>> Yes, it is a bug. It has been fixed in the trunk
>>
>>
>> https://github.com/apache/httpcore/commit/7f6dc0fdbe1b84e43b78e86229917881f0e2252a
>>
>> Generally the server is expected to send 'connection: close' in response
>> to 'connection: close' in the request.
>>
>> Oleg
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: About SNI support in HC4.5

[Philippe Mouawad]

Ok, I understand , thanks Oleg.
I was just thinking that if you had the fix in new layers, it would maybe
be easy to fix it in deprecated ones. But I agree it might be loss of time
on your side.

On our side, as migration to 4.5.2 is not that easy and will surely take
time, it would have been helpful.

Regards
Philippe

On Wed, Dec 30, 2015 at 10:43 AM, Oleg Kalnichevski 
wrote:

> On Tue, 2015-12-29 at 09:22 +0100, Philippe Mouawad wrote:
> > Hello Oleg,
> > Thanks for answer.
> > Could you elaborate a bit more on your answer ?
> >
> > Also, is there a chance that you fix the issue also in deprecated code of
> > httpclient (org.apache.http.conn.ssl.SSLSocketFactory) or is it too
> complex
> > ?
> >
>
> I personally see no point in fixing non-critical bugs in deprecated
> code. This time can be better spent elsewhere. However I can commit a
> fix though if contributed.
>
> Oleg
>
>
> > Thanks
> >
> > On Wednesday, December 23, 2015, Oleg Kalnichevski 
> wrote:
> >
> > > On Wed, 2015-12-23 at 14:30 +0100, Philippe Mouawad wrote:
> > > > Hi,
> > > > Any answer on the 1/ question ?
> > > > Thanks
> > > > Regards
> > > >
> > > > On Tue, Dec 22, 2015 at 2:39 PM, Philippe Mouawad <
> > > > philippe.moua...@gmail.com > wrote:
> > > >
> > > > > Hi,
> > > > > With further investigation, I answered to some of my questions.
> > > > >
> > > > > Regards
> > > > >
> > > > > On Mon, Dec 21, 2015 at 6:52 PM, Philippe Mouawad <
> > > > > philippe.moua...@gmail.com > wrote:
> > > > >
> > > > >> Hello,
> > > > >> Looking at:
> > > > >>
> > > > >>- https://issues.apache.org/jira/browse/HTTPCLIENT-1119
> > > > >>
> > > > >>
> > > > >> 1/ It is not clear for me how the fix works if commit association
> is
> > > > >> correct:
> > > > >>
> > > > >>-
> > > https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1544769
> > > > >>
> > > > >> Is the fix about replacing:
> > > > >>
> > > > >> final SSLSocket sock = (SSLSocket)
> this.socketfactory.createSocket();
> > > > >>
> > > > >> with :
> > > > >> SocketFactory.getDefault().createSocket();
> > >
> > > Pretty much. Please note though that the use of a plain socket instead
> > > of a fully initialized SSL socket causes a different execution path in
> > > #connectSocket method.
> > >
> > > Oleg
> > >
> > >
> > >
> > >
> >
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Connection:close header and HttpClient behaviour

[Philippe Mouawad]

Hi Oleg,
Thanks for answer.

Why is the fix not in 4.4.4 ? From commit date and release date of 4.4.4,
I  would say it should have been no ?

Bug from JIRA https://issues.apache.org/jira/browse/HTTPCORE-397, I see
fixVersion is 5.0-alpha1 but piece of code is not in 4.4.4


Thanks

On Wed, Dec 30, 2015 at 10:53 AM, Oleg Kalnichevski 
wrote:

> On Tue, 2015-12-29 at 17:34 +0100, Philippe Mouawad wrote:
> > Hello,
> > We have a bug report in JMeter :
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=58583
> >
> > To summarize, setting "Connection: close" header in the requests does not
> > make HttpClient close the connection on the client side.
> >
> > It seems to be a violation of RFC 2616:
> > http://tools.ietf.org/html/rfc2616#page-45
> > http://tools.ietf.org/html/rfc2616#section-14.10
> >
> >
> > And RFC7230:
> > http://tools.ietf.org/html/rfc7230#section-6.1
> >
> >
> > I am not sure what to think about this.
> >
>
> Yes, it is a bug. It has been fixed in the trunk
>
>
> https://github.com/apache/httpcore/commit/7f6dc0fdbe1b84e43b78e86229917881f0e2252a
>
> Generally the server is expected to send 'connection: close' in response
> to 'connection: close' in the request.
>
> Oleg
>
>


-- 
Cordialement.
Philippe Mouawad.

Connection:close header and HttpClient behaviour

[Philippe Mouawad]

Hello,
We have a bug report in JMeter :
https://bz.apache.org/bugzilla/show_bug.cgi?id=58583

To summarize, setting "Connection: close" header in the requests does not
make HttpClient close the connection on the client side.

It seems to be a violation of RFC 2616:
http://tools.ietf.org/html/rfc2616#page-45
http://tools.ietf.org/html/rfc2616#section-14.10


And RFC7230:
http://tools.ietf.org/html/rfc7230#section-6.1


I am not sure what to think about this.


Regards
Philippe

Re: About SNI support in HC4.5

[Philippe Mouawad]

Hello Oleg,
Thanks for answer.
Could you elaborate a bit more on your answer ?

Also, is there a chance that you fix the issue also in deprecated code of
httpclient (org.apache.http.conn.ssl.SSLSocketFactory) or is it too complex
?

Thanks

On Wednesday, December 23, 2015, Oleg Kalnichevski  wrote:

> On Wed, 2015-12-23 at 14:30 +0100, Philippe Mouawad wrote:
> > Hi,
> > Any answer on the 1/ question ?
> > Thanks
> > Regards
> >
> > On Tue, Dec 22, 2015 at 2:39 PM, Philippe Mouawad <
> > philippe.moua...@gmail.com > wrote:
> >
> > > Hi,
> > > With further investigation, I answered to some of my questions.
> > >
> > > Regards
> > >
> > > On Mon, Dec 21, 2015 at 6:52 PM, Philippe Mouawad <
> > > philippe.moua...@gmail.com > wrote:
> > >
> > >> Hello,
> > >> Looking at:
> > >>
> > >>- https://issues.apache.org/jira/browse/HTTPCLIENT-1119
> > >>
> > >>
> > >> 1/ It is not clear for me how the fix works if commit association is
> > >> correct:
> > >>
> > >>-
> https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1544769
> > >>
> > >> Is the fix about replacing:
> > >>
> > >> final SSLSocket sock = (SSLSocket) this.socketfactory.createSocket();
> > >>
> > >> with :
> > >> SocketFactory.getDefault().createSocket();
>
> Pretty much. Please note though that the use of a plain socket instead
> of a fully initialized SSL socket causes a different execution path in
> #connectSocket method.
>
> Oleg
>
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: About SNI support in HC4.5

[Philippe Mouawad]

Hi,
Any answer on the 1/ question ?
Thanks
Regards

On Tue, Dec 22, 2015 at 2:39 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hi,
> With further investigation, I answered to some of my questions.
>
> Regards
>
> On Mon, Dec 21, 2015 at 6:52 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> Hello,
>> Looking at:
>>
>>- https://issues.apache.org/jira/browse/HTTPCLIENT-1119
>>
>>
>> 1/ It is not clear for me how the fix works if commit association is
>> correct:
>>
>>- https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1544769
>>
>> Is the fix about replacing:
>>
>> final SSLSocket sock = (SSLSocket) this.socketfactory.createSocket();
>>
>> with :
>> SocketFactory.getDefault().createSocket();
>> 2/ Is the fix only for Java 7 or does it work on Java 8?
>>
> > It also works on Java8
>
>>
>> 3/ Also wondering, I see only SSLConnectionSocketFactory is concerned by
>> fix, so I suppose that SSLSocketFactory was not fixed ?
>> So I suppose that upgrading to HC4.5.1 from HC4.2.3 will not fix the
>> issue unless
>> SSLSocketFactory is used instead of
>> SSLConnectionSocketFactory
>>
>
> > No it will not fix the issue, unless  SSLSocketFactory is used instead
> of  SSLConnectionSocketFactory.
>
>>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: About SNI support in HC4.5

[Philippe Mouawad]

Hi,
With further investigation, I answered to some of my questions.

Regards

On Mon, Dec 21, 2015 at 6:52 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> Looking at:
>
>- https://issues.apache.org/jira/browse/HTTPCLIENT-1119
>
>
> 1/ It is not clear for me how the fix works if commit association is
> correct:
>
>- https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1544769
>
> Is the fix about replacing:
>
> final SSLSocket sock = (SSLSocket) this.socketfactory.createSocket();
>
> with :
> SocketFactory.getDefault().createSocket();
> 2/ Is the fix only for Java 7 or does it work on Java 8?
>
> It also works on Java8

>
> 3/ Also wondering, I see only SSLConnectionSocketFactory is concerned by
> fix, so I suppose that SSLSocketFactory was not fixed ?
> So I suppose that upgrading to HC4.5.1 from HC4.2.3 will not fix the issue
> unless
> SSLSocketFactory is used instead of
> SSLConnectionSocketFactory
>

> No it will not fix the issue, unless  SSLSocketFactory is used instead
of  SSLConnectionSocketFactory.

>

About SNI support in HC4.5

[Philippe Mouawad]

Hello,
Looking at:

   - https://issues.apache.org/jira/browse/HTTPCLIENT-1119


1/ It is not clear for me how the fix works if commit association is
correct:

   - https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1544769

Is the fix about replacing:

final SSLSocket sock = (SSLSocket) this.socketfactory.createSocket();

with :
SocketFactory.getDefault().createSocket();
2/ Is the fix only for Java 7 or does it work on Java 8?

3/ Also wondering, I see only SSLConnectionSocketFactory is concerned by
fix, so I suppose that SSLSocketFactory was not fixed ?
So I suppose that upgrading to HC4.5.1 from HC4.2.3 will not fix the issue
unless
SSLSocketFactory is used instead of
SSLConnectionSocketFactory
-- 
Cordialement.
Philippe Mouawad.

Re: httpClient.getConnectionManager() performance with HTTP only

[Philippe Mouawad]

Hi Oleg,
Back to this old subject and knowing that we must stick to 1 HttpClient per
thread (as per all the discussion that followed this).
Is there a plan to implement this lazy init of SSLContext in HttpClient as
it used to be the case in HC3 ?

For our project, it's a killer in terms of performance, and for other use
cases, it appears kind of weird that an SSLContext is initialized even for
a pure HTTP traffic.

Thanks
Regards



On Thu, May 15, 2014 at 10:39 AM, Oleg Kalnichevski 
wrote:

> On Wed, 2014-05-14 at 19:46 +0100, sebb wrote:
> > On 14 May 2014 12:28, Oleg Kalnichevski  wrote:
>
> ...
>
> > >> Issue is not present in HTTPCLient 3.1
> > >
> > > Philippe
> > >
> > > If HttpClient is used correctly, this code should only be executed only
> > > once. Why does JMeter create more than one instance of HttpClient?
> >
> > We currently create an instance for each instance of different proxy
> > settings and each protocol and each authority, because the client is
> > created with these settings.
> >
> > This is also done for each thread.
> >
> > IIRC, this was necessary originally. We have not rewritten the code
> > yet to use all the latest features.
> >
>
> I see. For the time what you can do is to use a custom SSL socket
> factory that lazily initializes SSL context when requested for the first
> time. This is exactly what HC 3.1 does. It will be somewhat slower given
> that one would need to mutex to synchronize access to the initialization
> code.
>
> Oleg
>
> > > Oleg
> > >
> >
> > ---------
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> >
>
>
>


-- 
Cordialement.
Philippe Mouawad.