You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Karl Wright <da...@gmail.com> on 2014/05/21 14:52:19 UTC
Expect-continue doesn't seem operative using 4.3.x builder structures
Hi Oleg,
A few months back, if you will recall, I ported much of ManifoldCF to use
the HttpClient 4.3 builder structures for its various connectors.
Unfortunately, one thing we'd previously fixed came unfixed when I did
this. We have a user who has a site that is being posted to that requires
basic auth. We were getting an exception with HttpClient 4.2 having to do
with non-repeatable request entities. We solved that by turning on
expect-continue.
For 4.3, we still have expect-continue on, but now we are getting similar
problems:
>>>>>>
Caused by: org.apache.http.client.NonRepeatableRequestException:
Cannot retry request with a non-repeatable request entity.
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:208)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
>>>>>>
The code used to set up HttpClient looks like this:
>>>>>>
RequestConfig.Builder requestBuilder = RequestConfig.custom()
.setCircularRedirectsAllowed(true)
.setSocketTimeout(socketTimeout)
.setStaleConnectionCheckEnabled(true)
.setExpectContinueEnabled(true)
.setConnectTimeout(connectionTimeout)
.setConnectionRequestTimeout(socketTimeout);
HttpClientBuilder clientBuilder = HttpClients.custom()
.setConnectionManager(connectionManager)
.setMaxConnTotal(1)
.disableAutomaticRetries()
.setDefaultRequestConfig(requestBuilder.build())
.setRedirectStrategy(new DefaultRedirectStrategy())
.setSSLSocketFactory(myFactory)
.setRequestExecutor(new HttpRequestExecutor(socketTimeout))
.setDefaultSocketConfig(SocketConfig.custom()
.setTcpNoDelay(true)
.setSoTimeout(socketTimeout)
.build()
);
if (userID != null && userID.length() > 0 && password != null)
{
CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
Credentials credentials = new
UsernamePasswordCredentials(userID, password);
if (realm != null)
credentialsProvider.setCredentials(new
AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, realm),
credentials);
else
credentialsProvider.setCredentials(AuthScope.ANY, credentials);
clientBuilder.setDefaultCredentialsProvider(credentialsProvider);
}
HttpClient localClient = clientBuilder.build();
<<<<<<
Wire logs show *no* expect/continue at all taking place. Can you tell
me what we are doing wrong?
Thanks,
Karl
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
FWIW, if it helps you can look at the complete log here:
http://folk.uio.no/erlendfg/manifoldcf/manifoldcf.log
This includes GETs to other machines as well as POSTs to Solr. It's the
POSTs though that are what is failing.
Karl
On Wed, May 21, 2014 at 10:01 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Oleg,
>
> Here are the headers it sends in our case. This is 4.3.3.
>
> >>>>>>
>
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST /solr/uio/update/extract HTTP/1.1
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Content-Type: application/xml; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Content-Charset: UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host: solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Content-Type: multipart/form-data; boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host: solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Transfer-Encoding: chunked[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Content-Type: application/xml; charset=UTF-8[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host: solr-test01.uio.no:443[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Connection: Keep-Alive[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Accept-Encoding: gzip,deflate[\r][\n]"
> <<<<<<
>
> Expect-continue is *not* firing, as you can see. Something else we are doing in the builder, or maybe that httpclient is doing, is apparently preventing it.
>
> Suggestions for how to quickly debug this problem?
>
> Karl
>
>
>
>
> On Wed, May 21, 2014 at 9:24 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
>> On Wed, 2014-05-21 at 08:52 -0400, Karl Wright wrote:
>> > Hi Oleg,
>> >
>> > A few months back, if you will recall, I ported much of ManifoldCF to
>> use
>> > the HttpClient 4.3 builder structures for its various connectors.
>> >
>> > Unfortunately, one thing we'd previously fixed came unfixed when I did
>> > this. We have a user who has a site that is being posted to that
>> requires
>> > basic auth. We were getting an exception with HttpClient 4.2 having to
>> do
>> > with non-repeatable request entities. We solved that by turning on
>> > expect-continue.
>> >
>> > For 4.3, we still have expect-continue on, but now we are getting
>> similar
>> > problems:
>> >
>> > >>>>>>
>> >
>> > Caused by: org.apache.http.client.NonRepeatableRequestException:
>> > Cannot retry request with a non-repeatable request entity.
>> > at
>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:208)
>> > at
>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
>> > at
>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
>> > at
>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
>> > >>>>>>
>> >
>> > The code used to set up HttpClient looks like this:
>> >
>> > >>>>>>
>> > RequestConfig.Builder requestBuilder = RequestConfig.custom()
>> > .setCircularRedirectsAllowed(true)
>> > .setSocketTimeout(socketTimeout)
>> > .setStaleConnectionCheckEnabled(true)
>> > .setExpectContinueEnabled(true)
>> > .setConnectTimeout(connectionTimeout)
>> > .setConnectionRequestTimeout(socketTimeout);
>> >
>> > HttpClientBuilder clientBuilder = HttpClients.custom()
>> > .setConnectionManager(connectionManager)
>> > .setMaxConnTotal(1)
>> > .disableAutomaticRetries()
>> > .setDefaultRequestConfig(requestBuilder.build())
>> > .setRedirectStrategy(new DefaultRedirectStrategy())
>> > .setSSLSocketFactory(myFactory)
>> > .setRequestExecutor(new HttpRequestExecutor(socketTimeout))
>> > .setDefaultSocketConfig(SocketConfig.custom()
>> > .setTcpNoDelay(true)
>> > .setSoTimeout(socketTimeout)
>> > .build()
>> > );
>> >
>> >
>> > if (userID != null && userID.length() > 0 && password != null)
>> > {
>> > CredentialsProvider credentialsProvider = new
>> BasicCredentialsProvider();
>> > Credentials credentials = new
>> > UsernamePasswordCredentials(userID, password);
>> > if (realm != null)
>> > credentialsProvider.setCredentials(new
>> > AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, realm),
>> > credentials);
>> > else
>> > credentialsProvider.setCredentials(AuthScope.ANY, credentials);
>> >
>> > clientBuilder.setDefaultCredentialsProvider(credentialsProvider);
>> > }
>> >
>> > HttpClient localClient = clientBuilder.build();
>> > <<<<<<
>> >
>> > Wire logs show *no* expect/continue at all taking place. Can you tell
>> > me what we are doing wrong?
>> >
>> > Thanks,
>> > Karl
>>
>> I see nothing wrong with your code. At the same time I executed the test
>> app below and got the expected behavior with regards to the
>> expect-continue handshaking.
>>
>> ---
>> RequestConfig requestConfig = RequestConfig.custom()
>> .setExpectContinueEnabled(true)
>> .build();
>> CloseableHttpClient client = HttpClients.custom()
>> .setDefaultRequestConfig(requestConfig)
>> .build();
>> HttpPost post = new HttpPost("http://www.google.ch/");
>> post.setEntity(new StringEntity("stuff", ContentType.TEXT_PLAIN));
>> CloseableHttpResponse response = client.execute(post);
>> try {
>>
>> } finally {
>> response.close();
>> }
>> ---
>>
>> ---
>> [DEBUG] RequestAddCookies - CookieSpec selected: best-match
>> [DEBUG] RequestAuthCache - Auth cache not set in the context
>> [DEBUG] PoolingHttpClientConnectionManager - Connection request: [route:
>> {}->http://www.google.ch:80][total kept alive: 0; route allocated: 0 of
>> 2; total allocated: 0 of 20]
>> [DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id:
>> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
>> allocated: 1 of 2; total allocated: 1 of 20]
>> [DEBUG] MainClientExec - Opening connection {}->http://www.google.ch:80
>> [DEBUG] HttpClientConnectionOperator - Connecting to
>> www.google.ch/173.194.113.152:80
>> [DEBUG] HttpClientConnectionOperator - Connection established
>> 192.168.42.101:39266<->173.194.113.152:80
>> [DEBUG] MainClientExec - Executing request POST / HTTP/1.1
>> [DEBUG] MainClientExec - Target auth state: UNCHALLENGED
>> [DEBUG] MainClientExec - Proxy auth state: UNCHALLENGED
>> [DEBUG] headers - http-outgoing-0 >> POST / HTTP/1.1
>> [DEBUG] headers - http-outgoing-0 >> Content-Length: 5
>> [DEBUG] headers - http-outgoing-0 >> Content-Type: text/plain;
>> charset=ISO-8859-1
>> [DEBUG] headers - http-outgoing-0 >> Host: www.google.ch
>> [DEBUG] headers - http-outgoing-0 >> Connection: Keep-Alive
>> [DEBUG] headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.3.3
>> (java 1.5)
>> [DEBUG] headers - http-outgoing-0 >> Expect: 100-continue
>> [DEBUG] headers - http-outgoing-0 >> Accept-Encoding: gzip,deflate
>> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 100 Continue
>> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 405 Method Not Allowed
>> [DEBUG] headers - http-outgoing-0 << Content-Type: text/html;
>> charset=UTF-8
>> [DEBUG] headers - http-outgoing-0 << Content-Length: 1453
>> [DEBUG] headers - http-outgoing-0 << Allow: GET, HEAD
>> [DEBUG] headers - http-outgoing-0 << Alternate-Protocol: 80:quic
>> [DEBUG] headers - http-outgoing-0 << Date: Wed, 21 May 2014 13:19:01 GMT
>> [DEBUG] headers - http-outgoing-0 << Server: gws
>> [DEBUG] headers - http-outgoing-0 << X-Frame-Options: SAMEORIGIN
>> [DEBUG] headers - http-outgoing-0 << X-XSS-Protection: 1; mode=block
>> [DEBUG] MainClientExec - Connection can be kept alive indefinitely
>> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown
>> connection
>> [DEBUG] MainClientExec - Connection discarded
>> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Close
>> connection
>> [DEBUG] PoolingHttpClientConnectionManager - Connection released: [id:
>> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
>> allocated: 0 of 2; total allocated: 0 of 20]
>> ---
>>
>> Oleg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
FWIW, if it helps you can look at the complete log here:
http://folk.uio.no/erlendfg/manifoldcf/manifoldcf.log
This includes GETs to other machines as well as POSTs to Solr. It's the
POSTs though that are what is failing.
Karl
On Wed, May 21, 2014 at 10:01 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Oleg,
>
> Here are the headers it sends in our case. This is 4.3.3.
>
> >>>>>>
>
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST /solr/uio/update/extract HTTP/1.1
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Content-Type: application/xml; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Content-Charset: UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host: solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Content-Type: multipart/form-data; boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host: solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Transfer-Encoding: chunked[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Content-Type: application/xml; charset=UTF-8[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host: solr-test01.uio.no:443[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Connection: Keep-Alive[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Accept-Encoding: gzip,deflate[\r][\n]"
> <<<<<<
>
> Expect-continue is *not* firing, as you can see. Something else we are doing in the builder, or maybe that httpclient is doing, is apparently preventing it.
>
> Suggestions for how to quickly debug this problem?
>
> Karl
>
>
>
>
> On Wed, May 21, 2014 at 9:24 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
>> On Wed, 2014-05-21 at 08:52 -0400, Karl Wright wrote:
>> > Hi Oleg,
>> >
>> > A few months back, if you will recall, I ported much of ManifoldCF to
>> use
>> > the HttpClient 4.3 builder structures for its various connectors.
>> >
>> > Unfortunately, one thing we'd previously fixed came unfixed when I did
>> > this. We have a user who has a site that is being posted to that
>> requires
>> > basic auth. We were getting an exception with HttpClient 4.2 having to
>> do
>> > with non-repeatable request entities. We solved that by turning on
>> > expect-continue.
>> >
>> > For 4.3, we still have expect-continue on, but now we are getting
>> similar
>> > problems:
>> >
>> > >>>>>>
>> >
>> > Caused by: org.apache.http.client.NonRepeatableRequestException:
>> > Cannot retry request with a non-repeatable request entity.
>> > at
>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:208)
>> > at
>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
>> > at
>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
>> > at
>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
>> > >>>>>>
>> >
>> > The code used to set up HttpClient looks like this:
>> >
>> > >>>>>>
>> > RequestConfig.Builder requestBuilder = RequestConfig.custom()
>> > .setCircularRedirectsAllowed(true)
>> > .setSocketTimeout(socketTimeout)
>> > .setStaleConnectionCheckEnabled(true)
>> > .setExpectContinueEnabled(true)
>> > .setConnectTimeout(connectionTimeout)
>> > .setConnectionRequestTimeout(socketTimeout);
>> >
>> > HttpClientBuilder clientBuilder = HttpClients.custom()
>> > .setConnectionManager(connectionManager)
>> > .setMaxConnTotal(1)
>> > .disableAutomaticRetries()
>> > .setDefaultRequestConfig(requestBuilder.build())
>> > .setRedirectStrategy(new DefaultRedirectStrategy())
>> > .setSSLSocketFactory(myFactory)
>> > .setRequestExecutor(new HttpRequestExecutor(socketTimeout))
>> > .setDefaultSocketConfig(SocketConfig.custom()
>> > .setTcpNoDelay(true)
>> > .setSoTimeout(socketTimeout)
>> > .build()
>> > );
>> >
>> >
>> > if (userID != null && userID.length() > 0 && password != null)
>> > {
>> > CredentialsProvider credentialsProvider = new
>> BasicCredentialsProvider();
>> > Credentials credentials = new
>> > UsernamePasswordCredentials(userID, password);
>> > if (realm != null)
>> > credentialsProvider.setCredentials(new
>> > AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, realm),
>> > credentials);
>> > else
>> > credentialsProvider.setCredentials(AuthScope.ANY, credentials);
>> >
>> > clientBuilder.setDefaultCredentialsProvider(credentialsProvider);
>> > }
>> >
>> > HttpClient localClient = clientBuilder.build();
>> > <<<<<<
>> >
>> > Wire logs show *no* expect/continue at all taking place. Can you tell
>> > me what we are doing wrong?
>> >
>> > Thanks,
>> > Karl
>>
>> I see nothing wrong with your code. At the same time I executed the test
>> app below and got the expected behavior with regards to the
>> expect-continue handshaking.
>>
>> ---
>> RequestConfig requestConfig = RequestConfig.custom()
>> .setExpectContinueEnabled(true)
>> .build();
>> CloseableHttpClient client = HttpClients.custom()
>> .setDefaultRequestConfig(requestConfig)
>> .build();
>> HttpPost post = new HttpPost("http://www.google.ch/");
>> post.setEntity(new StringEntity("stuff", ContentType.TEXT_PLAIN));
>> CloseableHttpResponse response = client.execute(post);
>> try {
>>
>> } finally {
>> response.close();
>> }
>> ---
>>
>> ---
>> [DEBUG] RequestAddCookies - CookieSpec selected: best-match
>> [DEBUG] RequestAuthCache - Auth cache not set in the context
>> [DEBUG] PoolingHttpClientConnectionManager - Connection request: [route:
>> {}->http://www.google.ch:80][total kept alive: 0; route allocated: 0 of
>> 2; total allocated: 0 of 20]
>> [DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id:
>> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
>> allocated: 1 of 2; total allocated: 1 of 20]
>> [DEBUG] MainClientExec - Opening connection {}->http://www.google.ch:80
>> [DEBUG] HttpClientConnectionOperator - Connecting to
>> www.google.ch/173.194.113.152:80
>> [DEBUG] HttpClientConnectionOperator - Connection established
>> 192.168.42.101:39266<->173.194.113.152:80
>> [DEBUG] MainClientExec - Executing request POST / HTTP/1.1
>> [DEBUG] MainClientExec - Target auth state: UNCHALLENGED
>> [DEBUG] MainClientExec - Proxy auth state: UNCHALLENGED
>> [DEBUG] headers - http-outgoing-0 >> POST / HTTP/1.1
>> [DEBUG] headers - http-outgoing-0 >> Content-Length: 5
>> [DEBUG] headers - http-outgoing-0 >> Content-Type: text/plain;
>> charset=ISO-8859-1
>> [DEBUG] headers - http-outgoing-0 >> Host: www.google.ch
>> [DEBUG] headers - http-outgoing-0 >> Connection: Keep-Alive
>> [DEBUG] headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.3.3
>> (java 1.5)
>> [DEBUG] headers - http-outgoing-0 >> Expect: 100-continue
>> [DEBUG] headers - http-outgoing-0 >> Accept-Encoding: gzip,deflate
>> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 100 Continue
>> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 405 Method Not Allowed
>> [DEBUG] headers - http-outgoing-0 << Content-Type: text/html;
>> charset=UTF-8
>> [DEBUG] headers - http-outgoing-0 << Content-Length: 1453
>> [DEBUG] headers - http-outgoing-0 << Allow: GET, HEAD
>> [DEBUG] headers - http-outgoing-0 << Alternate-Protocol: 80:quic
>> [DEBUG] headers - http-outgoing-0 << Date: Wed, 21 May 2014 13:19:01 GMT
>> [DEBUG] headers - http-outgoing-0 << Server: gws
>> [DEBUG] headers - http-outgoing-0 << X-Frame-Options: SAMEORIGIN
>> [DEBUG] headers - http-outgoing-0 << X-XSS-Protection: 1; mode=block
>> [DEBUG] MainClientExec - Connection can be kept alive indefinitely
>> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown
>> connection
>> [DEBUG] MainClientExec - Connection discarded
>> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Close
>> connection
>> [DEBUG] PoolingHttpClientConnectionManager - Connection released: [id:
>> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
>> allocated: 0 of 2; total allocated: 0 of 20]
>> ---
>>
>> Oleg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
I've created HTTPCLIENT-1510 to summarize the problem and propose the
outlines of a solution.
Karl
On Thu, May 22, 2014 at 8:27 AM, Karl Wright <da...@gmail.com> wrote:
> Let me clarify. Right now, you've a wrapper hierarchy that is totally
> distinct from the original request hierarchy. You *could* allow everything
> wrapped with HttpRequestWrapper to allow expect/continue, in which case you
> lose the ability to have specificity for different kinds of wrapped
> requests. Or (much better) you could have all HttpRequest objects have a
> "supportExpectContinue" method, which in the wrapper would wind up calling
> the embedded request's supportExpectContinue method. Seems much better, no?
>
> Karl
>
>
> On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
>
>> >>>>>>
>> Are you sure about that? What would this method do for GET requests
>> given than those requests are not even supposed to enclose an entity?
>> <<<<<<
>>
>> It would return false for any request implementation that did not support
>> expect-continue, of course.
>> The advantage of this kind of structure is that it does not rely on the
>> implicit instanceof operator, but rather an explicit method implementation,
>> so it is clearer (and more flexible).
>>
>> Karl
>>
>>
>>
>> On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>>
>>> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
>>> > FWIW, a better way for this kind of thing to be done would be for the
>>> > request object to have a method, e.g. "supportsExpectContinue()", that
>>> you
>>> > would call, instead of relying on class names and hierarchy ...
>>> >
>>>
>>> Are you sure about that? What would this method do for GET requests
>>> given than those requests are not even supposed to enclose an entity?
>>>
>>> Oleg
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: dev-help@hc.apache.org
>>>
>>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2014-05-23 at 08:38 -0400, Karl Wright wrote:
> >>>>>>
> I personally would not be in favor of throwing an IllegalStateException
> in case of conflicting configurations for the compatibility sake. My
> preference would be either to log a big, scary warning or investing some
> time into making HttpClientParamConfig capable merging old style and new
> style configurations, the latter being the preferred option.
> <<<<<<
>
> Your preferred option is fine with me, and would make things more backwards
> compatible. But I thought you wanted to get away from supported deprecated
> code. ;-)
>
> Karl
>
Not necessarily, as long as I do not have to write that code myself.
Oleg.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
>>>>>>
I personally would not be in favor of throwing an IllegalStateException
in case of conflicting configurations for the compatibility sake. My
preference would be either to log a big, scary warning or investing some
time into making HttpClientParamConfig capable merging old style and new
style configurations, the latter being the preferred option.
<<<<<<
Your preferred option is fine with me, and would make things more backwards
compatible. But I thought you wanted to get away from supported deprecated
code. ;-)
Karl
On Fri, May 23, 2014 at 8:25 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-05-22 at 18:16 -0400, Karl Wright wrote:
> > The resolution to this problem was simple -- after I audited both
> > HttpClient and SolrJ code.
> >
> > (0) Expect/continue handling, in the POST-case I was looking at, was in
> > fact *off*. It was disguised by the fact that the thread ID differed
> and I
> > did not note that in the log when I looked at it.
> > (1) In InternalHttpClient, if *any* configuration parameters are set,
> then
> > configuration parameters are used, and the RequestConfig is *thrown
> away*.
> > (2) In HttpSolrServer, randomly, it sets *one* configuration parameter,
> > namely one turning on redirection handling. This was actually in the
> code
> > I included in the ticket, and it was sufficient to completely throw away
> my
> > builder-created configuration.
> > (3) The solution was to create a modified version of HttpSolrServer and
> fix
> > the code so that it didn't do that.
> >
> > Any of the following would have been very helpful:
> >
> > (a) At least, output a log message when both parameters AND Config object
> > were present.
> > (b) Documentation (javadoc) making the implemented behavior clear.
> > (c) Ideally, if you set a parameter and you've already got a Config
> object,
> > an IllegalStateException should be thrown.
> >
> > This would have likely made it much quicker to diagnose than repeated
> > debugging sessions, via patched diagnostic jars, with clients half a
> world
> > away. Better to fail immediately than give the impression that things
> were
> > okay when they were not. Thoughts?
> >
>
> HttpParams interface and related classes are deprecated, aren't they?
>
> I personally would not be in favor of throwing an IllegalStateException
> in case of conflicting configurations for the compatibility sake. My
> preference would be either to log a big, scary warning or investing some
> time into making HttpClientParamConfig capable merging old style and new
> style configurations, the latter being the preferred option.
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-05-22 at 18:16 -0400, Karl Wright wrote:
> The resolution to this problem was simple -- after I audited both
> HttpClient and SolrJ code.
>
> (0) Expect/continue handling, in the POST-case I was looking at, was in
> fact *off*. It was disguised by the fact that the thread ID differed and I
> did not note that in the log when I looked at it.
> (1) In InternalHttpClient, if *any* configuration parameters are set, then
> configuration parameters are used, and the RequestConfig is *thrown away*.
> (2) In HttpSolrServer, randomly, it sets *one* configuration parameter,
> namely one turning on redirection handling. This was actually in the code
> I included in the ticket, and it was sufficient to completely throw away my
> builder-created configuration.
> (3) The solution was to create a modified version of HttpSolrServer and fix
> the code so that it didn't do that.
>
> Any of the following would have been very helpful:
>
> (a) At least, output a log message when both parameters AND Config object
> were present.
> (b) Documentation (javadoc) making the implemented behavior clear.
> (c) Ideally, if you set a parameter and you've already got a Config object,
> an IllegalStateException should be thrown.
>
> This would have likely made it much quicker to diagnose than repeated
> debugging sessions, via patched diagnostic jars, with clients half a world
> away. Better to fail immediately than give the impression that things were
> okay when they were not. Thoughts?
>
HttpParams interface and related classes are deprecated, aren't they?
I personally would not be in favor of throwing an IllegalStateException
in case of conflicting configurations for the compatibility sake. My
preference would be either to log a big, scary warning or investing some
time into making HttpClientParamConfig capable merging old style and new
style configurations, the latter being the preferred option.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
The resolution to this problem was simple -- after I audited both
HttpClient and SolrJ code.
(0) Expect/continue handling, in the POST-case I was looking at, was in
fact *off*. It was disguised by the fact that the thread ID differed and I
did not note that in the log when I looked at it.
(1) In InternalHttpClient, if *any* configuration parameters are set, then
configuration parameters are used, and the RequestConfig is *thrown away*.
(2) In HttpSolrServer, randomly, it sets *one* configuration parameter,
namely one turning on redirection handling. This was actually in the code
I included in the ticket, and it was sufficient to completely throw away my
builder-created configuration.
(3) The solution was to create a modified version of HttpSolrServer and fix
the code so that it didn't do that.
Any of the following would have been very helpful:
(a) At least, output a log message when both parameters AND Config object
were present.
(b) Documentation (javadoc) making the implemented behavior clear.
(c) Ideally, if you set a parameter and you've already got a Config object,
an IllegalStateException should be thrown.
This would have likely made it much quicker to diagnose than repeated
debugging sessions, via patched diagnostic jars, with clients half a world
away. Better to fail immediately than give the impression that things were
okay when they were not. Thoughts?
Karl
On Thu, May 22, 2014 at 9:05 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Oleg,
>
> This is the order of events in the code in question -- which has not
> changed, by the way, since we went for 4.2.x to 4.3.3:
>
> - ManifoldCF creates an HttpClient instance
> - ManifoldCF hands the HttpClient instance to SolrJ (a solr library)
> - SolrJ posts to Solr using multipart post
>
> We don't get to specify how SolrJ wraps its entities, or even IF it wraps
> its entities. (My recollection is that it doesn't do any kind of explicit
> wrapping.) And in any case I certainly don't understand the reasons behind
> every line of SolrJ client code.
>
> If your claim is that you can do multipart entity posts in HttpClient
> without using a class derived from HttpRequestWrapper, fine, then I will
> look into the SolrJ code and find a way to work around SolrJ's
> implementation.
>
> Please leave HTTPCLIENT-1510 open until I am done with my SolrJ review.
>
> Karl
>
>
>
> On Thu, May 22, 2014 at 8:56 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
>> On Thu, 2014-05-22 at 08:43 -0400, Karl Wright wrote:
>> > Hi Oleg,
>> >
>> > We *are* using POST - multipart post. And this apparently extends
>> > HttpRequestWrapper. Which is why expect/continue is not working for us.
>> >
>>
>> Why? What for? Even if you are absolutely certain wrapping is necessary
>> in this case why then not use HttpRequestWrapper#wrap instead of class
>> extension? The constructor of this class even intentionally made private
>> to discourage people from its extension.
>>
>> > If you have a better solution, please let me know what it is.
>> >
>>
>> What shall I do about HTTPCLIENT-1510? API elegancy, which is subjective
>> and contentious topic, aside it is clearly not a bug with HttpClient.
>>
>> Oleg
>>
>> > Karl
>> >
>> >
>> >
>> > On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <ol...@apache.org>
>> wrote:
>> >
>> > > On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
>> > > > Let me clarify. Right now, you've a wrapper hierarchy that is
>> totally
>> > > > distinct from the original request hierarchy. You *could* allow
>> > > everything
>> > > > wrapped with HttpRequestWrapper to allow expect/continue, in which
>> case
>> > > you
>> > > > lose the ability to have specificity for different kinds of wrapped
>> > > > requests. Or (much better) you could have all HttpRequest objects
>> have a
>> > > > "supportExpectContinue" method, which in the wrapper would wind up
>> > > calling
>> > > > the embedded request's supportExpectContinue method. Seems much
>> better,
>> > > no?
>> > > >
>> > >
>> > > Why is exactly instanceof bad or less flexible? It enables certain
>> > > requests to provide optional behavior such as ability to enclose a
>> > > request entity, which by the current official HTTP spec applies to
>> POST
>> > > and PUT _only_.
>> > >
>> > > So, what is better, round or green?
>> > >
>> > > Oleg
>> > >
>> > > > Karl
>> > > >
>> > > >
>> > > > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com>
>> wrote:
>> > > >
>> > > > > >>>>>>
>> > > > > Are you sure about that? What would this method do for GET
>> requests
>> > > > > given than those requests are not even supposed to enclose an
>> entity?
>> > > > > <<<<<<
>> > > > >
>> > > > > It would return false for any request implementation that did not
>> > > support
>> > > > > expect-continue, of course.
>> > > > > The advantage of this kind of structure is that it does not rely
>> on the
>> > > > > implicit instanceof operator, but rather an explicit method
>> > > implementation,
>> > > > > so it is clearer (and more flexible).
>> > > > >
>> > > > > Karl
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <
>> olegk@apache.org
>> > > >wrote:
>> > > > >
>> > > > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
>> > > > >> > FWIW, a better way for this kind of thing to be done would be
>> for
>> > > the
>> > > > >> > request object to have a method, e.g.
>> "supportsExpectContinue()",
>> > > that
>> > > > >> you
>> > > > >> > would call, instead of relying on class names and hierarchy ...
>> > > > >> >
>> > > > >>
>> > > > >> Are you sure about that? What would this method do for GET
>> requests
>> > > > >> given than those requests are not even supposed to enclose an
>> entity?
>> > > > >>
>> > > > >> Oleg
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>
>> ---------------------------------------------------------------------
>> > > > >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > > > >> For additional commands, e-mail: dev-help@hc.apache.org
>> > > > >>
>> > > > >>
>> > > > >
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > > For additional commands, e-mail: dev-help@hc.apache.org
>> > >
>> > >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
This is the order of events in the code in question -- which has not
changed, by the way, since we went for 4.2.x to 4.3.3:
- ManifoldCF creates an HttpClient instance
- ManifoldCF hands the HttpClient instance to SolrJ (a solr library)
- SolrJ posts to Solr using multipart post
We don't get to specify how SolrJ wraps its entities, or even IF it wraps
its entities. (My recollection is that it doesn't do any kind of explicit
wrapping.) And in any case I certainly don't understand the reasons behind
every line of SolrJ client code.
If your claim is that you can do multipart entity posts in HttpClient
without using a class derived from HttpRequestWrapper, fine, then I will
look into the SolrJ code and find a way to work around SolrJ's
implementation.
Please leave HTTPCLIENT-1510 open until I am done with my SolrJ review.
Karl
On Thu, May 22, 2014 at 8:56 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-05-22 at 08:43 -0400, Karl Wright wrote:
> > Hi Oleg,
> >
> > We *are* using POST - multipart post. And this apparently extends
> > HttpRequestWrapper. Which is why expect/continue is not working for us.
> >
>
> Why? What for? Even if you are absolutely certain wrapping is necessary
> in this case why then not use HttpRequestWrapper#wrap instead of class
> extension? The constructor of this class even intentionally made private
> to discourage people from its extension.
>
> > If you have a better solution, please let me know what it is.
> >
>
> What shall I do about HTTPCLIENT-1510? API elegancy, which is subjective
> and contentious topic, aside it is clearly not a bug with HttpClient.
>
> Oleg
>
> > Karl
> >
> >
> >
> > On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > > On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> > > > Let me clarify. Right now, you've a wrapper hierarchy that is
> totally
> > > > distinct from the original request hierarchy. You *could* allow
> > > everything
> > > > wrapped with HttpRequestWrapper to allow expect/continue, in which
> case
> > > you
> > > > lose the ability to have specificity for different kinds of wrapped
> > > > requests. Or (much better) you could have all HttpRequest objects
> have a
> > > > "supportExpectContinue" method, which in the wrapper would wind up
> > > calling
> > > > the embedded request's supportExpectContinue method. Seems much
> better,
> > > no?
> > > >
> > >
> > > Why is exactly instanceof bad or less flexible? It enables certain
> > > requests to provide optional behavior such as ability to enclose a
> > > request entity, which by the current official HTTP spec applies to POST
> > > and PUT _only_.
> > >
> > > So, what is better, round or green?
> > >
> > > Oleg
> > >
> > > > Karl
> > > >
> > > >
> > > > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com>
> wrote:
> > > >
> > > > > >>>>>>
> > > > > Are you sure about that? What would this method do for GET requests
> > > > > given than those requests are not even supposed to enclose an
> entity?
> > > > > <<<<<<
> > > > >
> > > > > It would return false for any request implementation that did not
> > > support
> > > > > expect-continue, of course.
> > > > > The advantage of this kind of structure is that it does not rely
> on the
> > > > > implicit instanceof operator, but rather an explicit method
> > > implementation,
> > > > > so it is clearer (and more flexible).
> > > > >
> > > > > Karl
> > > > >
> > > > >
> > > > >
> > > > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <
> olegk@apache.org
> > > >wrote:
> > > > >
> > > > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > > > >> > FWIW, a better way for this kind of thing to be done would be
> for
> > > the
> > > > >> > request object to have a method, e.g.
> "supportsExpectContinue()",
> > > that
> > > > >> you
> > > > >> > would call, instead of relying on class names and hierarchy ...
> > > > >> >
> > > > >>
> > > > >> Are you sure about that? What would this method do for GET
> requests
> > > > >> given than those requests are not even supposed to enclose an
> entity?
> > > > >>
> > > > >> Oleg
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > >> For additional commands, e-mail: dev-help@hc.apache.org
> > > > >>
> > > > >>
> > > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
This is the order of events in the code in question -- which has not
changed, by the way, since we went for 4.2.x to 4.3.3:
- ManifoldCF creates an HttpClient instance
- ManifoldCF hands the HttpClient instance to SolrJ (a solr library)
- SolrJ posts to Solr using multipart post
We don't get to specify how SolrJ wraps its entities, or even IF it wraps
its entities. (My recollection is that it doesn't do any kind of explicit
wrapping.) And in any case I certainly don't understand the reasons behind
every line of SolrJ client code.
If your claim is that you can do multipart entity posts in HttpClient
without using a class derived from HttpRequestWrapper, fine, then I will
look into the SolrJ code and find a way to work around SolrJ's
implementation.
Please leave HTTPCLIENT-1510 open until I am done with my SolrJ review.
Karl
On Thu, May 22, 2014 at 8:56 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-05-22 at 08:43 -0400, Karl Wright wrote:
> > Hi Oleg,
> >
> > We *are* using POST - multipart post. And this apparently extends
> > HttpRequestWrapper. Which is why expect/continue is not working for us.
> >
>
> Why? What for? Even if you are absolutely certain wrapping is necessary
> in this case why then not use HttpRequestWrapper#wrap instead of class
> extension? The constructor of this class even intentionally made private
> to discourage people from its extension.
>
> > If you have a better solution, please let me know what it is.
> >
>
> What shall I do about HTTPCLIENT-1510? API elegancy, which is subjective
> and contentious topic, aside it is clearly not a bug with HttpClient.
>
> Oleg
>
> > Karl
> >
> >
> >
> > On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > > On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> > > > Let me clarify. Right now, you've a wrapper hierarchy that is
> totally
> > > > distinct from the original request hierarchy. You *could* allow
> > > everything
> > > > wrapped with HttpRequestWrapper to allow expect/continue, in which
> case
> > > you
> > > > lose the ability to have specificity for different kinds of wrapped
> > > > requests. Or (much better) you could have all HttpRequest objects
> have a
> > > > "supportExpectContinue" method, which in the wrapper would wind up
> > > calling
> > > > the embedded request's supportExpectContinue method. Seems much
> better,
> > > no?
> > > >
> > >
> > > Why is exactly instanceof bad or less flexible? It enables certain
> > > requests to provide optional behavior such as ability to enclose a
> > > request entity, which by the current official HTTP spec applies to POST
> > > and PUT _only_.
> > >
> > > So, what is better, round or green?
> > >
> > > Oleg
> > >
> > > > Karl
> > > >
> > > >
> > > > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com>
> wrote:
> > > >
> > > > > >>>>>>
> > > > > Are you sure about that? What would this method do for GET requests
> > > > > given than those requests are not even supposed to enclose an
> entity?
> > > > > <<<<<<
> > > > >
> > > > > It would return false for any request implementation that did not
> > > support
> > > > > expect-continue, of course.
> > > > > The advantage of this kind of structure is that it does not rely
> on the
> > > > > implicit instanceof operator, but rather an explicit method
> > > implementation,
> > > > > so it is clearer (and more flexible).
> > > > >
> > > > > Karl
> > > > >
> > > > >
> > > > >
> > > > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <
> olegk@apache.org
> > > >wrote:
> > > > >
> > > > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > > > >> > FWIW, a better way for this kind of thing to be done would be
> for
> > > the
> > > > >> > request object to have a method, e.g.
> "supportsExpectContinue()",
> > > that
> > > > >> you
> > > > >> > would call, instead of relying on class names and hierarchy ...
> > > > >> >
> > > > >>
> > > > >> Are you sure about that? What would this method do for GET
> requests
> > > > >> given than those requests are not even supposed to enclose an
> entity?
> > > > >>
> > > > >> Oleg
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > >> For additional commands, e-mail: dev-help@hc.apache.org
> > > > >>
> > > > >>
> > > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-05-22 at 08:43 -0400, Karl Wright wrote:
> Hi Oleg,
>
> We *are* using POST - multipart post. And this apparently extends
> HttpRequestWrapper. Which is why expect/continue is not working for us.
>
Why? What for? Even if you are absolutely certain wrapping is necessary
in this case why then not use HttpRequestWrapper#wrap instead of class
extension? The constructor of this class even intentionally made private
to discourage people from its extension.
> If you have a better solution, please let me know what it is.
>
What shall I do about HTTPCLIENT-1510? API elegancy, which is subjective
and contentious topic, aside it is clearly not a bug with HttpClient.
Oleg
> Karl
>
>
>
> On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> > > Let me clarify. Right now, you've a wrapper hierarchy that is totally
> > > distinct from the original request hierarchy. You *could* allow
> > everything
> > > wrapped with HttpRequestWrapper to allow expect/continue, in which case
> > you
> > > lose the ability to have specificity for different kinds of wrapped
> > > requests. Or (much better) you could have all HttpRequest objects have a
> > > "supportExpectContinue" method, which in the wrapper would wind up
> > calling
> > > the embedded request's supportExpectContinue method. Seems much better,
> > no?
> > >
> >
> > Why is exactly instanceof bad or less flexible? It enables certain
> > requests to provide optional behavior such as ability to enclose a
> > request entity, which by the current official HTTP spec applies to POST
> > and PUT _only_.
> >
> > So, what is better, round or green?
> >
> > Oleg
> >
> > > Karl
> > >
> > >
> > > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
> > >
> > > > >>>>>>
> > > > Are you sure about that? What would this method do for GET requests
> > > > given than those requests are not even supposed to enclose an entity?
> > > > <<<<<<
> > > >
> > > > It would return false for any request implementation that did not
> > support
> > > > expect-continue, of course.
> > > > The advantage of this kind of structure is that it does not rely on the
> > > > implicit instanceof operator, but rather an explicit method
> > implementation,
> > > > so it is clearer (and more flexible).
> > > >
> > > > Karl
> > > >
> > > >
> > > >
> > > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <olegk@apache.org
> > >wrote:
> > > >
> > > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > > >> > FWIW, a better way for this kind of thing to be done would be for
> > the
> > > >> > request object to have a method, e.g. "supportsExpectContinue()",
> > that
> > > >> you
> > > >> > would call, instead of relying on class names and hierarchy ...
> > > >> >
> > > >>
> > > >> Are you sure about that? What would this method do for GET requests
> > > >> given than those requests are not even supposed to enclose an entity?
> > > >>
> > > >> Oleg
> > > >>
> > > >>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > >> For additional commands, e-mail: dev-help@hc.apache.org
> > > >>
> > > >>
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-05-22 at 08:43 -0400, Karl Wright wrote:
> Hi Oleg,
>
> We *are* using POST - multipart post. And this apparently extends
> HttpRequestWrapper. Which is why expect/continue is not working for us.
>
Why? What for? Even if you are absolutely certain wrapping is necessary
in this case why then not use HttpRequestWrapper#wrap instead of class
extension? The constructor of this class even intentionally made private
to discourage people from its extension.
> If you have a better solution, please let me know what it is.
>
What shall I do about HTTPCLIENT-1510? API elegancy, which is subjective
and contentious topic, aside it is clearly not a bug with HttpClient.
Oleg
> Karl
>
>
>
> On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> > > Let me clarify. Right now, you've a wrapper hierarchy that is totally
> > > distinct from the original request hierarchy. You *could* allow
> > everything
> > > wrapped with HttpRequestWrapper to allow expect/continue, in which case
> > you
> > > lose the ability to have specificity for different kinds of wrapped
> > > requests. Or (much better) you could have all HttpRequest objects have a
> > > "supportExpectContinue" method, which in the wrapper would wind up
> > calling
> > > the embedded request's supportExpectContinue method. Seems much better,
> > no?
> > >
> >
> > Why is exactly instanceof bad or less flexible? It enables certain
> > requests to provide optional behavior such as ability to enclose a
> > request entity, which by the current official HTTP spec applies to POST
> > and PUT _only_.
> >
> > So, what is better, round or green?
> >
> > Oleg
> >
> > > Karl
> > >
> > >
> > > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
> > >
> > > > >>>>>>
> > > > Are you sure about that? What would this method do for GET requests
> > > > given than those requests are not even supposed to enclose an entity?
> > > > <<<<<<
> > > >
> > > > It would return false for any request implementation that did not
> > support
> > > > expect-continue, of course.
> > > > The advantage of this kind of structure is that it does not rely on the
> > > > implicit instanceof operator, but rather an explicit method
> > implementation,
> > > > so it is clearer (and more flexible).
> > > >
> > > > Karl
> > > >
> > > >
> > > >
> > > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <olegk@apache.org
> > >wrote:
> > > >
> > > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > > >> > FWIW, a better way for this kind of thing to be done would be for
> > the
> > > >> > request object to have a method, e.g. "supportsExpectContinue()",
> > that
> > > >> you
> > > >> > would call, instead of relying on class names and hierarchy ...
> > > >> >
> > > >>
> > > >> Are you sure about that? What would this method do for GET requests
> > > >> given than those requests are not even supposed to enclose an entity?
> > > >>
> > > >> Oleg
> > > >>
> > > >>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > >> For additional commands, e-mail: dev-help@hc.apache.org
> > > >>
> > > >>
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
We *are* using POST - multipart post. And this apparently extends
HttpRequestWrapper. Which is why expect/continue is not working for us.
If you have a better solution, please let me know what it is.
Karl
On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> > Let me clarify. Right now, you've a wrapper hierarchy that is totally
> > distinct from the original request hierarchy. You *could* allow
> everything
> > wrapped with HttpRequestWrapper to allow expect/continue, in which case
> you
> > lose the ability to have specificity for different kinds of wrapped
> > requests. Or (much better) you could have all HttpRequest objects have a
> > "supportExpectContinue" method, which in the wrapper would wind up
> calling
> > the embedded request's supportExpectContinue method. Seems much better,
> no?
> >
>
> Why is exactly instanceof bad or less flexible? It enables certain
> requests to provide optional behavior such as ability to enclose a
> request entity, which by the current official HTTP spec applies to POST
> and PUT _only_.
>
> So, what is better, round or green?
>
> Oleg
>
> > Karl
> >
> >
> > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
> >
> > > >>>>>>
> > > Are you sure about that? What would this method do for GET requests
> > > given than those requests are not even supposed to enclose an entity?
> > > <<<<<<
> > >
> > > It would return false for any request implementation that did not
> support
> > > expect-continue, of course.
> > > The advantage of this kind of structure is that it does not rely on the
> > > implicit instanceof operator, but rather an explicit method
> implementation,
> > > so it is clearer (and more flexible).
> > >
> > > Karl
> > >
> > >
> > >
> > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <olegk@apache.org
> >wrote:
> > >
> > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > >> > FWIW, a better way for this kind of thing to be done would be for
> the
> > >> > request object to have a method, e.g. "supportsExpectContinue()",
> that
> > >> you
> > >> > would call, instead of relying on class names and hierarchy ...
> > >> >
> > >>
> > >> Are you sure about that? What would this method do for GET requests
> > >> given than those requests are not even supposed to enclose an entity?
> > >>
> > >> Oleg
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > >> For additional commands, e-mail: dev-help@hc.apache.org
> > >>
> > >>
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
We *are* using POST - multipart post. And this apparently extends
HttpRequestWrapper. Which is why expect/continue is not working for us.
If you have a better solution, please let me know what it is.
Karl
On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> > Let me clarify. Right now, you've a wrapper hierarchy that is totally
> > distinct from the original request hierarchy. You *could* allow
> everything
> > wrapped with HttpRequestWrapper to allow expect/continue, in which case
> you
> > lose the ability to have specificity for different kinds of wrapped
> > requests. Or (much better) you could have all HttpRequest objects have a
> > "supportExpectContinue" method, which in the wrapper would wind up
> calling
> > the embedded request's supportExpectContinue method. Seems much better,
> no?
> >
>
> Why is exactly instanceof bad or less flexible? It enables certain
> requests to provide optional behavior such as ability to enclose a
> request entity, which by the current official HTTP spec applies to POST
> and PUT _only_.
>
> So, what is better, round or green?
>
> Oleg
>
> > Karl
> >
> >
> > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
> >
> > > >>>>>>
> > > Are you sure about that? What would this method do for GET requests
> > > given than those requests are not even supposed to enclose an entity?
> > > <<<<<<
> > >
> > > It would return false for any request implementation that did not
> support
> > > expect-continue, of course.
> > > The advantage of this kind of structure is that it does not rely on the
> > > implicit instanceof operator, but rather an explicit method
> implementation,
> > > so it is clearer (and more flexible).
> > >
> > > Karl
> > >
> > >
> > >
> > > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <olegk@apache.org
> >wrote:
> > >
> > >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > >> > FWIW, a better way for this kind of thing to be done would be for
> the
> > >> > request object to have a method, e.g. "supportsExpectContinue()",
> that
> > >> you
> > >> > would call, instead of relying on class names and hierarchy ...
> > >> >
> > >>
> > >> Are you sure about that? What would this method do for GET requests
> > >> given than those requests are not even supposed to enclose an entity?
> > >>
> > >> Oleg
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > >> For additional commands, e-mail: dev-help@hc.apache.org
> > >>
> > >>
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> Let me clarify. Right now, you've a wrapper hierarchy that is totally
> distinct from the original request hierarchy. You *could* allow everything
> wrapped with HttpRequestWrapper to allow expect/continue, in which case you
> lose the ability to have specificity for different kinds of wrapped
> requests. Or (much better) you could have all HttpRequest objects have a
> "supportExpectContinue" method, which in the wrapper would wind up calling
> the embedded request's supportExpectContinue method. Seems much better, no?
>
Why is exactly instanceof bad or less flexible? It enables certain
requests to provide optional behavior such as ability to enclose a
request entity, which by the current official HTTP spec applies to POST
and PUT _only_.
So, what is better, round or green?
Oleg
> Karl
>
>
> On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
>
> > >>>>>>
> > Are you sure about that? What would this method do for GET requests
> > given than those requests are not even supposed to enclose an entity?
> > <<<<<<
> >
> > It would return false for any request implementation that did not support
> > expect-continue, of course.
> > The advantage of this kind of structure is that it does not rely on the
> > implicit instanceof operator, but rather an explicit method implementation,
> > so it is clearer (and more flexible).
> >
> > Karl
> >
> >
> >
> > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
> >
> >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> >> > FWIW, a better way for this kind of thing to be done would be for the
> >> > request object to have a method, e.g. "supportsExpectContinue()", that
> >> you
> >> > would call, instead of relying on class names and hierarchy ...
> >> >
> >>
> >> Are you sure about that? What would this method do for GET requests
> >> given than those requests are not even supposed to enclose an entity?
> >>
> >> Oleg
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: dev-help@hc.apache.org
> >>
> >>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-05-22 at 08:27 -0400, Karl Wright wrote:
> Let me clarify. Right now, you've a wrapper hierarchy that is totally
> distinct from the original request hierarchy. You *could* allow everything
> wrapped with HttpRequestWrapper to allow expect/continue, in which case you
> lose the ability to have specificity for different kinds of wrapped
> requests. Or (much better) you could have all HttpRequest objects have a
> "supportExpectContinue" method, which in the wrapper would wind up calling
> the embedded request's supportExpectContinue method. Seems much better, no?
>
Why is exactly instanceof bad or less flexible? It enables certain
requests to provide optional behavior such as ability to enclose a
request entity, which by the current official HTTP spec applies to POST
and PUT _only_.
So, what is better, round or green?
Oleg
> Karl
>
>
> On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
>
> > >>>>>>
> > Are you sure about that? What would this method do for GET requests
> > given than those requests are not even supposed to enclose an entity?
> > <<<<<<
> >
> > It would return false for any request implementation that did not support
> > expect-continue, of course.
> > The advantage of this kind of structure is that it does not rely on the
> > implicit instanceof operator, but rather an explicit method implementation,
> > so it is clearer (and more flexible).
> >
> > Karl
> >
> >
> >
> > On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
> >
> >> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> >> > FWIW, a better way for this kind of thing to be done would be for the
> >> > request object to have a method, e.g. "supportsExpectContinue()", that
> >> you
> >> > would call, instead of relying on class names and hierarchy ...
> >> >
> >>
> >> Are you sure about that? What would this method do for GET requests
> >> given than those requests are not even supposed to enclose an entity?
> >>
> >> Oleg
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> >> For additional commands, e-mail: dev-help@hc.apache.org
> >>
> >>
> >
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
I've created HTTPCLIENT-1510 to summarize the problem and propose the
outlines of a solution.
Karl
On Thu, May 22, 2014 at 8:27 AM, Karl Wright <da...@gmail.com> wrote:
> Let me clarify. Right now, you've a wrapper hierarchy that is totally
> distinct from the original request hierarchy. You *could* allow everything
> wrapped with HttpRequestWrapper to allow expect/continue, in which case you
> lose the ability to have specificity for different kinds of wrapped
> requests. Or (much better) you could have all HttpRequest objects have a
> "supportExpectContinue" method, which in the wrapper would wind up calling
> the embedded request's supportExpectContinue method. Seems much better, no?
>
> Karl
>
>
> On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
>
>> >>>>>>
>> Are you sure about that? What would this method do for GET requests
>> given than those requests are not even supposed to enclose an entity?
>> <<<<<<
>>
>> It would return false for any request implementation that did not support
>> expect-continue, of course.
>> The advantage of this kind of structure is that it does not rely on the
>> implicit instanceof operator, but rather an explicit method implementation,
>> so it is clearer (and more flexible).
>>
>> Karl
>>
>>
>>
>> On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>>
>>> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
>>> > FWIW, a better way for this kind of thing to be done would be for the
>>> > request object to have a method, e.g. "supportsExpectContinue()", that
>>> you
>>> > would call, instead of relying on class names and hierarchy ...
>>> >
>>>
>>> Are you sure about that? What would this method do for GET requests
>>> given than those requests are not even supposed to enclose an entity?
>>>
>>> Oleg
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: dev-help@hc.apache.org
>>>
>>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Let me clarify. Right now, you've a wrapper hierarchy that is totally
distinct from the original request hierarchy. You *could* allow everything
wrapped with HttpRequestWrapper to allow expect/continue, in which case you
lose the ability to have specificity for different kinds of wrapped
requests. Or (much better) you could have all HttpRequest objects have a
"supportExpectContinue" method, which in the wrapper would wind up calling
the embedded request's supportExpectContinue method. Seems much better, no?
Karl
On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
> >>>>>>
> Are you sure about that? What would this method do for GET requests
> given than those requests are not even supposed to enclose an entity?
> <<<<<<
>
> It would return false for any request implementation that did not support
> expect-continue, of course.
> The advantage of this kind of structure is that it does not rely on the
> implicit instanceof operator, but rather an explicit method implementation,
> so it is clearer (and more flexible).
>
> Karl
>
>
>
> On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
>> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
>> > FWIW, a better way for this kind of thing to be done would be for the
>> > request object to have a method, e.g. "supportsExpectContinue()", that
>> you
>> > would call, instead of relying on class names and hierarchy ...
>> >
>>
>> Are you sure about that? What would this method do for GET requests
>> given than those requests are not even supposed to enclose an entity?
>>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Let me clarify. Right now, you've a wrapper hierarchy that is totally
distinct from the original request hierarchy. You *could* allow everything
wrapped with HttpRequestWrapper to allow expect/continue, in which case you
lose the ability to have specificity for different kinds of wrapped
requests. Or (much better) you could have all HttpRequest objects have a
"supportExpectContinue" method, which in the wrapper would wind up calling
the embedded request's supportExpectContinue method. Seems much better, no?
Karl
On Thu, May 22, 2014 at 8:23 AM, Karl Wright <da...@gmail.com> wrote:
> >>>>>>
> Are you sure about that? What would this method do for GET requests
> given than those requests are not even supposed to enclose an entity?
> <<<<<<
>
> It would return false for any request implementation that did not support
> expect-continue, of course.
> The advantage of this kind of structure is that it does not rely on the
> implicit instanceof operator, but rather an explicit method implementation,
> so it is clearer (and more flexible).
>
> Karl
>
>
>
> On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org>wrote:
>
>> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
>> > FWIW, a better way for this kind of thing to be done would be for the
>> > request object to have a method, e.g. "supportsExpectContinue()", that
>> you
>> > would call, instead of relying on class names and hierarchy ...
>> >
>>
>> Are you sure about that? What would this method do for GET requests
>> given than those requests are not even supposed to enclose an entity?
>>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
>>>>>>
Are you sure about that? What would this method do for GET requests
given than those requests are not even supposed to enclose an entity?
<<<<<<
It would return false for any request implementation that did not support
expect-continue, of course.
The advantage of this kind of structure is that it does not rely on the
implicit instanceof operator, but rather an explicit method implementation,
so it is clearer (and more flexible).
Karl
On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > FWIW, a better way for this kind of thing to be done would be for the
> > request object to have a method, e.g. "supportsExpectContinue()", that
> you
> > would call, instead of relying on class names and hierarchy ...
> >
>
> Are you sure about that? What would this method do for GET requests
> given than those requests are not even supposed to enclose an entity?
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
>>>>>>
Are you sure about that? What would this method do for GET requests
given than those requests are not even supposed to enclose an entity?
<<<<<<
It would return false for any request implementation that did not support
expect-continue, of course.
The advantage of this kind of structure is that it does not rely on the
implicit instanceof operator, but rather an explicit method implementation,
so it is clearer (and more flexible).
Karl
On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> > FWIW, a better way for this kind of thing to be done would be for the
> > request object to have a method, e.g. "supportsExpectContinue()", that
> you
> > would call, instead of relying on class names and hierarchy ...
> >
>
> Are you sure about that? What would this method do for GET requests
> given than those requests are not even supposed to enclose an entity?
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> FWIW, a better way for this kind of thing to be done would be for the
> request object to have a method, e.g. "supportsExpectContinue()", that you
> would call, instead of relying on class names and hierarchy ...
>
Are you sure about that? What would this method do for GET requests
given than those requests are not even supposed to enclose an entity?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote:
> FWIW, a better way for this kind of thing to be done would be for the
> request object to have a method, e.g. "supportsExpectContinue()", that you
> would call, instead of relying on class names and hierarchy ...
>
Are you sure about that? What would this method do for GET requests
given than those requests are not even supposed to enclose an entity?
Oleg
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
FWIW, a better way for this kind of thing to be done would be for the
request object to have a method, e.g. "supportsExpectContinue()", that you
would call, instead of relying on class names and hierarchy ...
Karl
On Thu, May 22, 2014 at 7:10 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Oleg,
>
> Debugging indicates that it doesn't like the incoming request class:
>
> DEBUG 2014-05-22 12:07:55,464 (Thread-553) - request is NOT instance of HttpEntityEnclosingRequest: org.apache.http.client.methods.HttpRequestWrapper
>
>
> This is happening here:
>
> if (request instanceof HttpEntityEnclosingRequest) {
>
> What is this check intended to acheive?
>
> Karl
>
>
>
>
> On Wed, May 21, 2014 at 10:23 AM, Oleg Kalnichevski <
> oleg@ok2consulting.com> wrote:
>
>> On Wed, 2014-05-21 at 10:01 -0400, Karl Wright wrote:
>> > Hi Oleg,
>> >
>> > Here are the headers it sends in our case. This is 4.3.3.
>> >
>> > >>>>>>
>> >
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
>> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
>> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
>> > Transfer-Encoding: chunked
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
>> > /solr/uio/update/extract HTTP/1.1
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
>> > Content-Type: application/xml; charset=UTF-8
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Content-Charset: UTF-8
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
>> > solr-test01.uio.no:443
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
>> > Connection: Keep-Alive
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Transfer-Encoding: chunked
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
>> > Accept-Encoding: gzip,deflate
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Content-Type: multipart/form-data;
>> > boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
>> > solr-test01.uio.no:443
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Connection: Keep-Alive
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Accept-Encoding: gzip,deflate
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
>> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
>> > 1.0[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Transfer-Encoding: chunked[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Content-Type: application/xml; charset=UTF-8[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
>> > solr-test01.uio.no:443[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Connection: Keep-Alive[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Accept-Encoding: gzip,deflate[\r][\n]"
>> > <<<<<<
>> >
>> > Expect-continue is *not* firing, as you can see. Something else we
>> > are doing in the builder, or maybe that httpclient is doing, is
>> > apparently preventing it.
>> >
>> > Suggestions for how to quickly debug this problem?
>> >
>>
>> Try debugging this protocol interceptor
>>
>>
>> http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/xref/org/apache/http/client/protocol/RequestExpectContinue.html#61
>>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
FWIW, a better way for this kind of thing to be done would be for the
request object to have a method, e.g. "supportsExpectContinue()", that you
would call, instead of relying on class names and hierarchy ...
Karl
On Thu, May 22, 2014 at 7:10 AM, Karl Wright <da...@gmail.com> wrote:
> Hi Oleg,
>
> Debugging indicates that it doesn't like the incoming request class:
>
> DEBUG 2014-05-22 12:07:55,464 (Thread-553) - request is NOT instance of HttpEntityEnclosingRequest: org.apache.http.client.methods.HttpRequestWrapper
>
>
> This is happening here:
>
> if (request instanceof HttpEntityEnclosingRequest) {
>
> What is this check intended to acheive?
>
> Karl
>
>
>
>
> On Wed, May 21, 2014 at 10:23 AM, Oleg Kalnichevski <
> oleg@ok2consulting.com> wrote:
>
>> On Wed, 2014-05-21 at 10:01 -0400, Karl Wright wrote:
>> > Hi Oleg,
>> >
>> > Here are the headers it sends in our case. This is 4.3.3.
>> >
>> > >>>>>>
>> >
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
>> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
>> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
>> > Transfer-Encoding: chunked
>> > DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
>> > /solr/uio/update/extract HTTP/1.1
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
>> > Content-Type: application/xml; charset=UTF-8
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Content-Charset: UTF-8
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
>> > solr-test01.uio.no:443
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
>> > Connection: Keep-Alive
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Transfer-Encoding: chunked
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
>> > Accept-Encoding: gzip,deflate
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Content-Type: multipart/form-data;
>> > boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
>> > solr-test01.uio.no:443
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Connection: Keep-Alive
>> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
>> > Accept-Encoding: gzip,deflate
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
>> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
>> > 1.0[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Transfer-Encoding: chunked[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Content-Type: application/xml; charset=UTF-8[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
>> > solr-test01.uio.no:443[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Connection: Keep-Alive[\r][\n]"
>> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
>> > "Accept-Encoding: gzip,deflate[\r][\n]"
>> > <<<<<<
>> >
>> > Expect-continue is *not* firing, as you can see. Something else we
>> > are doing in the builder, or maybe that httpclient is doing, is
>> > apparently preventing it.
>> >
>> > Suggestions for how to quickly debug this problem?
>> >
>>
>> Try debugging this protocol interceptor
>>
>>
>> http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/xref/org/apache/http/client/protocol/RequestExpectContinue.html#61
>>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
Debugging indicates that it doesn't like the incoming request class:
DEBUG 2014-05-22 12:07:55,464 (Thread-553) - request is NOT instance
of HttpEntityEnclosingRequest:
org.apache.http.client.methods.HttpRequestWrapper
This is happening here:
if (request instanceof HttpEntityEnclosingRequest) {
What is this check intended to acheive?
Karl
On Wed, May 21, 2014 at 10:23 AM, Oleg Kalnichevski
<ol...@ok2consulting.com>wrote:
> On Wed, 2014-05-21 at 10:01 -0400, Karl Wright wrote:
> > Hi Oleg,
> >
> > Here are the headers it sends in our case. This is 4.3.3.
> >
> > >>>>>>
> >
> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> > Transfer-Encoding: chunked
> > DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
> > /solr/uio/update/extract HTTP/1.1
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> > Content-Type: application/xml; charset=UTF-8
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Content-Charset: UTF-8
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
> > solr-test01.uio.no:443
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> > Connection: Keep-Alive
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Transfer-Encoding: chunked
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> > Accept-Encoding: gzip,deflate
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Content-Type: multipart/form-data;
> > boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
> > solr-test01.uio.no:443
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Connection: Keep-Alive
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Accept-Encoding: gzip,deflate
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
> > 1.0[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Transfer-Encoding: chunked[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Content-Type: application/xml; charset=UTF-8[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
> > solr-test01.uio.no:443[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Connection: Keep-Alive[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Accept-Encoding: gzip,deflate[\r][\n]"
> > <<<<<<
> >
> > Expect-continue is *not* firing, as you can see. Something else we
> > are doing in the builder, or maybe that httpclient is doing, is
> > apparently preventing it.
> >
> > Suggestions for how to quickly debug this problem?
> >
>
> Try debugging this protocol interceptor
>
>
> http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/xref/org/apache/http/client/protocol/RequestExpectContinue.html#61
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
Debugging indicates that it doesn't like the incoming request class:
DEBUG 2014-05-22 12:07:55,464 (Thread-553) - request is NOT instance
of HttpEntityEnclosingRequest:
org.apache.http.client.methods.HttpRequestWrapper
This is happening here:
if (request instanceof HttpEntityEnclosingRequest) {
What is this check intended to acheive?
Karl
On Wed, May 21, 2014 at 10:23 AM, Oleg Kalnichevski
<ol...@ok2consulting.com>wrote:
> On Wed, 2014-05-21 at 10:01 -0400, Karl Wright wrote:
> > Hi Oleg,
> >
> > Here are the headers it sends in our case. This is 4.3.3.
> >
> > >>>>>>
> >
> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> > DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> > Transfer-Encoding: chunked
> > DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
> > /solr/uio/update/extract HTTP/1.1
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> > Content-Type: application/xml; charset=UTF-8
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Content-Charset: UTF-8
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
> > solr-test01.uio.no:443
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> > Connection: Keep-Alive
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Transfer-Encoding: chunked
> > DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> > Accept-Encoding: gzip,deflate
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Content-Type: multipart/form-data;
> > boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
> > solr-test01.uio.no:443
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Connection: Keep-Alive
> > DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> > Accept-Encoding: gzip,deflate
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
> > /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
> > 1.0[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Transfer-Encoding: chunked[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Content-Type: application/xml; charset=UTF-8[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
> > solr-test01.uio.no:443[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Connection: Keep-Alive[\r][\n]"
> > DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> > "Accept-Encoding: gzip,deflate[\r][\n]"
> > <<<<<<
> >
> > Expect-continue is *not* firing, as you can see. Something else we
> > are doing in the builder, or maybe that httpclient is doing, is
> > apparently preventing it.
> >
> > Suggestions for how to quickly debug this problem?
> >
>
> Try debugging this protocol interceptor
>
>
> http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/xref/org/apache/http/client/protocol/RequestExpectContinue.html#61
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@ok2consulting.com>.
On Wed, 2014-05-21 at 10:01 -0400, Karl Wright wrote:
> Hi Oleg,
>
> Here are the headers it sends in our case. This is 4.3.3.
>
> >>>>>>
>
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
> /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
> /solr/uio/update/extract HTTP/1.1
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> Content-Type: application/xml; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Content-Charset: UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
> solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Content-Type: multipart/form-data;
> boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
> solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
> /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
> 1.0[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Transfer-Encoding: chunked[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Content-Type: application/xml; charset=UTF-8[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
> solr-test01.uio.no:443[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Connection: Keep-Alive[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Accept-Encoding: gzip,deflate[\r][\n]"
> <<<<<<
>
> Expect-continue is *not* firing, as you can see. Something else we
> are doing in the builder, or maybe that httpclient is doing, is
> apparently preventing it.
>
> Suggestions for how to quickly debug this problem?
>
Try debugging this protocol interceptor
http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/xref/org/apache/http/client/protocol/RequestExpectContinue.html#61
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@ok2consulting.com>.
On Wed, 2014-05-21 at 10:01 -0400, Karl Wright wrote:
> Hi Oleg,
>
> Here are the headers it sends in our case. This is 4.3.3.
>
> >>>>>>
>
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
> /solr/uio/update?wt=xml&version=2.2 HTTP/1.1
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
> /solr/uio/update/extract HTTP/1.1
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> Content-Type: application/xml; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Content-Charset: UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
> solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Transfer-Encoding: chunked
> DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Content-Type: multipart/form-data;
> boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
> solr-test01.uio.no:443
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Connection: Keep-Alive
> DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
> Accept-Encoding: gzip,deflate
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
> /solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
> 1.0[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Transfer-Encoding: chunked[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Content-Type: application/xml; charset=UTF-8[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
> solr-test01.uio.no:443[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Connection: Keep-Alive[\r][\n]"
> DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
> "Accept-Encoding: gzip,deflate[\r][\n]"
> <<<<<<
>
> Expect-continue is *not* firing, as you can see. Something else we
> are doing in the builder, or maybe that httpclient is doing, is
> apparently preventing it.
>
> Suggestions for how to quickly debug this problem?
>
Try debugging this protocol interceptor
http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/xref/org/apache/http/client/protocol/RequestExpectContinue.html#61
Oleg
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
Here are the headers it sends in our case. This is 4.3.3.
>>>>>>
DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
/solr/uio/update?wt=xml&version=2.2 HTTP/1.1
DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
Transfer-Encoding: chunked
DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
/solr/uio/update/extract HTTP/1.1
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
Content-Type: application/xml; charset=UTF-8
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Content-Charset: UTF-8
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
solr-test01.uio.no:443
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
Connection: Keep-Alive
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Transfer-Encoding: chunked
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
Accept-Encoding: gzip,deflate
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Content-Type: multipart/form-data;
boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
solr-test01.uio.no:443
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Connection: Keep-Alive
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Accept-Encoding: gzip,deflate
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
/solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
1.0[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Transfer-Encoding: chunked[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Content-Type: application/xml; charset=UTF-8[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
solr-test01.uio.no:443[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Connection: Keep-Alive[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Accept-Encoding: gzip,deflate[\r][\n]"
<<<<<<
Expect-continue is *not* firing, as you can see. Something else we
are doing in the builder, or maybe that httpclient is doing, is
apparently preventing it.
Suggestions for how to quickly debug this problem?
Karl
On Wed, May 21, 2014 at 9:24 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2014-05-21 at 08:52 -0400, Karl Wright wrote:
> > Hi Oleg,
> >
> > A few months back, if you will recall, I ported much of ManifoldCF to use
> > the HttpClient 4.3 builder structures for its various connectors.
> >
> > Unfortunately, one thing we'd previously fixed came unfixed when I did
> > this. We have a user who has a site that is being posted to that
> requires
> > basic auth. We were getting an exception with HttpClient 4.2 having to
> do
> > with non-repeatable request entities. We solved that by turning on
> > expect-continue.
> >
> > For 4.3, we still have expect-continue on, but now we are getting similar
> > problems:
> >
> > >>>>>>
> >
> > Caused by: org.apache.http.client.NonRepeatableRequestException:
> > Cannot retry request with a non-repeatable request entity.
> > at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:208)
> > at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> > at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> > at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> > >>>>>>
> >
> > The code used to set up HttpClient looks like this:
> >
> > >>>>>>
> > RequestConfig.Builder requestBuilder = RequestConfig.custom()
> > .setCircularRedirectsAllowed(true)
> > .setSocketTimeout(socketTimeout)
> > .setStaleConnectionCheckEnabled(true)
> > .setExpectContinueEnabled(true)
> > .setConnectTimeout(connectionTimeout)
> > .setConnectionRequestTimeout(socketTimeout);
> >
> > HttpClientBuilder clientBuilder = HttpClients.custom()
> > .setConnectionManager(connectionManager)
> > .setMaxConnTotal(1)
> > .disableAutomaticRetries()
> > .setDefaultRequestConfig(requestBuilder.build())
> > .setRedirectStrategy(new DefaultRedirectStrategy())
> > .setSSLSocketFactory(myFactory)
> > .setRequestExecutor(new HttpRequestExecutor(socketTimeout))
> > .setDefaultSocketConfig(SocketConfig.custom()
> > .setTcpNoDelay(true)
> > .setSoTimeout(socketTimeout)
> > .build()
> > );
> >
> >
> > if (userID != null && userID.length() > 0 && password != null)
> > {
> > CredentialsProvider credentialsProvider = new
> BasicCredentialsProvider();
> > Credentials credentials = new
> > UsernamePasswordCredentials(userID, password);
> > if (realm != null)
> > credentialsProvider.setCredentials(new
> > AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, realm),
> > credentials);
> > else
> > credentialsProvider.setCredentials(AuthScope.ANY, credentials);
> >
> > clientBuilder.setDefaultCredentialsProvider(credentialsProvider);
> > }
> >
> > HttpClient localClient = clientBuilder.build();
> > <<<<<<
> >
> > Wire logs show *no* expect/continue at all taking place. Can you tell
> > me what we are doing wrong?
> >
> > Thanks,
> > Karl
>
> I see nothing wrong with your code. At the same time I executed the test
> app below and got the expected behavior with regards to the
> expect-continue handshaking.
>
> ---
> RequestConfig requestConfig = RequestConfig.custom()
> .setExpectContinueEnabled(true)
> .build();
> CloseableHttpClient client = HttpClients.custom()
> .setDefaultRequestConfig(requestConfig)
> .build();
> HttpPost post = new HttpPost("http://www.google.ch/");
> post.setEntity(new StringEntity("stuff", ContentType.TEXT_PLAIN));
> CloseableHttpResponse response = client.execute(post);
> try {
>
> } finally {
> response.close();
> }
> ---
>
> ---
> [DEBUG] RequestAddCookies - CookieSpec selected: best-match
> [DEBUG] RequestAuthCache - Auth cache not set in the context
> [DEBUG] PoolingHttpClientConnectionManager - Connection request: [route:
> {}->http://www.google.ch:80][total kept alive: 0; route allocated: 0 of
> 2; total allocated: 0 of 20]
> [DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id:
> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
> allocated: 1 of 2; total allocated: 1 of 20]
> [DEBUG] MainClientExec - Opening connection {}->http://www.google.ch:80
> [DEBUG] HttpClientConnectionOperator - Connecting to
> www.google.ch/173.194.113.152:80
> [DEBUG] HttpClientConnectionOperator - Connection established
> 192.168.42.101:39266<->173.194.113.152:80
> [DEBUG] MainClientExec - Executing request POST / HTTP/1.1
> [DEBUG] MainClientExec - Target auth state: UNCHALLENGED
> [DEBUG] MainClientExec - Proxy auth state: UNCHALLENGED
> [DEBUG] headers - http-outgoing-0 >> POST / HTTP/1.1
> [DEBUG] headers - http-outgoing-0 >> Content-Length: 5
> [DEBUG] headers - http-outgoing-0 >> Content-Type: text/plain;
> charset=ISO-8859-1
> [DEBUG] headers - http-outgoing-0 >> Host: www.google.ch
> [DEBUG] headers - http-outgoing-0 >> Connection: Keep-Alive
> [DEBUG] headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.3.3
> (java 1.5)
> [DEBUG] headers - http-outgoing-0 >> Expect: 100-continue
> [DEBUG] headers - http-outgoing-0 >> Accept-Encoding: gzip,deflate
> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 100 Continue
> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 405 Method Not Allowed
> [DEBUG] headers - http-outgoing-0 << Content-Type: text/html;
> charset=UTF-8
> [DEBUG] headers - http-outgoing-0 << Content-Length: 1453
> [DEBUG] headers - http-outgoing-0 << Allow: GET, HEAD
> [DEBUG] headers - http-outgoing-0 << Alternate-Protocol: 80:quic
> [DEBUG] headers - http-outgoing-0 << Date: Wed, 21 May 2014 13:19:01 GMT
> [DEBUG] headers - http-outgoing-0 << Server: gws
> [DEBUG] headers - http-outgoing-0 << X-Frame-Options: SAMEORIGIN
> [DEBUG] headers - http-outgoing-0 << X-XSS-Protection: 1; mode=block
> [DEBUG] MainClientExec - Connection can be kept alive indefinitely
> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown
> connection
> [DEBUG] MainClientExec - Connection discarded
> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Close
> connection
> [DEBUG] PoolingHttpClientConnectionManager - Connection released: [id:
> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
> allocated: 0 of 2; total allocated: 0 of 20]
> ---
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder structures
Posted by Karl Wright <da...@gmail.com>.
Hi Oleg,
Here are the headers it sends in our case. This is 4.3.3.
>>>>>>
DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >> POST
/solr/uio/update?wt=xml&version=2.2 HTTP/1.1
DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
DEBUG 2014-05-21 15:28:39,630 (Thread-449) - http-outgoing-6 >>
Transfer-Encoding: chunked
DEBUG 2014-05-21 15:28:39,630 (Thread-456) - http-outgoing-5 >> POST
/solr/uio/update/extract HTTP/1.1
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
Content-Type: application/xml; charset=UTF-8
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Content-Charset: UTF-8
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >> Host:
solr-test01.uio.no:443
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
Connection: Keep-Alive
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Transfer-Encoding: chunked
DEBUG 2014-05-21 15:28:39,631 (Thread-449) - http-outgoing-6 >>
Accept-Encoding: gzip,deflate
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Content-Type: multipart/form-data;
boundary=efUhz7rIZVmTta4q-godYmOjxfvqHlT3Ppmc; charset=UTF-8
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >> Host:
solr-test01.uio.no:443
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Connection: Keep-Alive
DEBUG 2014-05-21 15:28:39,631 (Thread-456) - http-outgoing-5 >>
Accept-Encoding: gzip,deflate
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "POST
/solr/uio/update?wt=xml&version=2.2 HTTP/1.1[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer]
1.0[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Transfer-Encoding: chunked[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Content-Type: application/xml; charset=UTF-8[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >> "Host:
solr-test01.uio.no:443[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Connection: Keep-Alive[\r][\n]"
DEBUG 2014-05-21 15:28:39,632 (Thread-449) - http-outgoing-6 >>
"Accept-Encoding: gzip,deflate[\r][\n]"
<<<<<<
Expect-continue is *not* firing, as you can see. Something else we
are doing in the builder, or maybe that httpclient is doing, is
apparently preventing it.
Suggestions for how to quickly debug this problem?
Karl
On Wed, May 21, 2014 at 9:24 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2014-05-21 at 08:52 -0400, Karl Wright wrote:
> > Hi Oleg,
> >
> > A few months back, if you will recall, I ported much of ManifoldCF to use
> > the HttpClient 4.3 builder structures for its various connectors.
> >
> > Unfortunately, one thing we'd previously fixed came unfixed when I did
> > this. We have a user who has a site that is being posted to that
> requires
> > basic auth. We were getting an exception with HttpClient 4.2 having to
> do
> > with non-repeatable request entities. We solved that by turning on
> > expect-continue.
> >
> > For 4.3, we still have expect-continue on, but now we are getting similar
> > problems:
> >
> > >>>>>>
> >
> > Caused by: org.apache.http.client.NonRepeatableRequestException:
> > Cannot retry request with a non-repeatable request entity.
> > at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:208)
> > at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> > at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> > at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> > >>>>>>
> >
> > The code used to set up HttpClient looks like this:
> >
> > >>>>>>
> > RequestConfig.Builder requestBuilder = RequestConfig.custom()
> > .setCircularRedirectsAllowed(true)
> > .setSocketTimeout(socketTimeout)
> > .setStaleConnectionCheckEnabled(true)
> > .setExpectContinueEnabled(true)
> > .setConnectTimeout(connectionTimeout)
> > .setConnectionRequestTimeout(socketTimeout);
> >
> > HttpClientBuilder clientBuilder = HttpClients.custom()
> > .setConnectionManager(connectionManager)
> > .setMaxConnTotal(1)
> > .disableAutomaticRetries()
> > .setDefaultRequestConfig(requestBuilder.build())
> > .setRedirectStrategy(new DefaultRedirectStrategy())
> > .setSSLSocketFactory(myFactory)
> > .setRequestExecutor(new HttpRequestExecutor(socketTimeout))
> > .setDefaultSocketConfig(SocketConfig.custom()
> > .setTcpNoDelay(true)
> > .setSoTimeout(socketTimeout)
> > .build()
> > );
> >
> >
> > if (userID != null && userID.length() > 0 && password != null)
> > {
> > CredentialsProvider credentialsProvider = new
> BasicCredentialsProvider();
> > Credentials credentials = new
> > UsernamePasswordCredentials(userID, password);
> > if (realm != null)
> > credentialsProvider.setCredentials(new
> > AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, realm),
> > credentials);
> > else
> > credentialsProvider.setCredentials(AuthScope.ANY, credentials);
> >
> > clientBuilder.setDefaultCredentialsProvider(credentialsProvider);
> > }
> >
> > HttpClient localClient = clientBuilder.build();
> > <<<<<<
> >
> > Wire logs show *no* expect/continue at all taking place. Can you tell
> > me what we are doing wrong?
> >
> > Thanks,
> > Karl
>
> I see nothing wrong with your code. At the same time I executed the test
> app below and got the expected behavior with regards to the
> expect-continue handshaking.
>
> ---
> RequestConfig requestConfig = RequestConfig.custom()
> .setExpectContinueEnabled(true)
> .build();
> CloseableHttpClient client = HttpClients.custom()
> .setDefaultRequestConfig(requestConfig)
> .build();
> HttpPost post = new HttpPost("http://www.google.ch/");
> post.setEntity(new StringEntity("stuff", ContentType.TEXT_PLAIN));
> CloseableHttpResponse response = client.execute(post);
> try {
>
> } finally {
> response.close();
> }
> ---
>
> ---
> [DEBUG] RequestAddCookies - CookieSpec selected: best-match
> [DEBUG] RequestAuthCache - Auth cache not set in the context
> [DEBUG] PoolingHttpClientConnectionManager - Connection request: [route:
> {}->http://www.google.ch:80][total kept alive: 0; route allocated: 0 of
> 2; total allocated: 0 of 20]
> [DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id:
> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
> allocated: 1 of 2; total allocated: 1 of 20]
> [DEBUG] MainClientExec - Opening connection {}->http://www.google.ch:80
> [DEBUG] HttpClientConnectionOperator - Connecting to
> www.google.ch/173.194.113.152:80
> [DEBUG] HttpClientConnectionOperator - Connection established
> 192.168.42.101:39266<->173.194.113.152:80
> [DEBUG] MainClientExec - Executing request POST / HTTP/1.1
> [DEBUG] MainClientExec - Target auth state: UNCHALLENGED
> [DEBUG] MainClientExec - Proxy auth state: UNCHALLENGED
> [DEBUG] headers - http-outgoing-0 >> POST / HTTP/1.1
> [DEBUG] headers - http-outgoing-0 >> Content-Length: 5
> [DEBUG] headers - http-outgoing-0 >> Content-Type: text/plain;
> charset=ISO-8859-1
> [DEBUG] headers - http-outgoing-0 >> Host: www.google.ch
> [DEBUG] headers - http-outgoing-0 >> Connection: Keep-Alive
> [DEBUG] headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.3.3
> (java 1.5)
> [DEBUG] headers - http-outgoing-0 >> Expect: 100-continue
> [DEBUG] headers - http-outgoing-0 >> Accept-Encoding: gzip,deflate
> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 100 Continue
> [DEBUG] headers - http-outgoing-0 << HTTP/1.1 405 Method Not Allowed
> [DEBUG] headers - http-outgoing-0 << Content-Type: text/html;
> charset=UTF-8
> [DEBUG] headers - http-outgoing-0 << Content-Length: 1453
> [DEBUG] headers - http-outgoing-0 << Allow: GET, HEAD
> [DEBUG] headers - http-outgoing-0 << Alternate-Protocol: 80:quic
> [DEBUG] headers - http-outgoing-0 << Date: Wed, 21 May 2014 13:19:01 GMT
> [DEBUG] headers - http-outgoing-0 << Server: gws
> [DEBUG] headers - http-outgoing-0 << X-Frame-Options: SAMEORIGIN
> [DEBUG] headers - http-outgoing-0 << X-XSS-Protection: 1; mode=block
> [DEBUG] MainClientExec - Connection can be kept alive indefinitely
> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown
> connection
> [DEBUG] MainClientExec - Connection discarded
> [DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Close
> connection
> [DEBUG] PoolingHttpClientConnectionManager - Connection released: [id:
> 0][route: {}->http://www.google.ch:80][total kept alive: 0; route
> allocated: 0 of 2; total allocated: 0 of 20]
> ---
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2014-05-21 at 08:52 -0400, Karl Wright wrote:
> Hi Oleg,
>
> A few months back, if you will recall, I ported much of ManifoldCF to use
> the HttpClient 4.3 builder structures for its various connectors.
>
> Unfortunately, one thing we'd previously fixed came unfixed when I did
> this. We have a user who has a site that is being posted to that requires
> basic auth. We were getting an exception with HttpClient 4.2 having to do
> with non-repeatable request entities. We solved that by turning on
> expect-continue.
>
> For 4.3, we still have expect-continue on, but now we are getting similar
> problems:
>
> >>>>>>
>
> Caused by: org.apache.http.client.NonRepeatableRequestException:
> Cannot retry request with a non-repeatable request entity.
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:208)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> >>>>>>
>
> The code used to set up HttpClient looks like this:
>
> >>>>>>
> RequestConfig.Builder requestBuilder = RequestConfig.custom()
> .setCircularRedirectsAllowed(true)
> .setSocketTimeout(socketTimeout)
> .setStaleConnectionCheckEnabled(true)
> .setExpectContinueEnabled(true)
> .setConnectTimeout(connectionTimeout)
> .setConnectionRequestTimeout(socketTimeout);
>
> HttpClientBuilder clientBuilder = HttpClients.custom()
> .setConnectionManager(connectionManager)
> .setMaxConnTotal(1)
> .disableAutomaticRetries()
> .setDefaultRequestConfig(requestBuilder.build())
> .setRedirectStrategy(new DefaultRedirectStrategy())
> .setSSLSocketFactory(myFactory)
> .setRequestExecutor(new HttpRequestExecutor(socketTimeout))
> .setDefaultSocketConfig(SocketConfig.custom()
> .setTcpNoDelay(true)
> .setSoTimeout(socketTimeout)
> .build()
> );
>
>
> if (userID != null && userID.length() > 0 && password != null)
> {
> CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
> Credentials credentials = new
> UsernamePasswordCredentials(userID, password);
> if (realm != null)
> credentialsProvider.setCredentials(new
> AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, realm),
> credentials);
> else
> credentialsProvider.setCredentials(AuthScope.ANY, credentials);
>
> clientBuilder.setDefaultCredentialsProvider(credentialsProvider);
> }
>
> HttpClient localClient = clientBuilder.build();
> <<<<<<
>
> Wire logs show *no* expect/continue at all taking place. Can you tell
> me what we are doing wrong?
>
> Thanks,
> Karl
I see nothing wrong with your code. At the same time I executed the test
app below and got the expected behavior with regards to the
expect-continue handshaking.
---
RequestConfig requestConfig = RequestConfig.custom()
.setExpectContinueEnabled(true)
.build();
CloseableHttpClient client = HttpClients.custom()
.setDefaultRequestConfig(requestConfig)
.build();
HttpPost post = new HttpPost("http://www.google.ch/");
post.setEntity(new StringEntity("stuff", ContentType.TEXT_PLAIN));
CloseableHttpResponse response = client.execute(post);
try {
} finally {
response.close();
}
---
---
[DEBUG] RequestAddCookies - CookieSpec selected: best-match
[DEBUG] RequestAuthCache - Auth cache not set in the context
[DEBUG] PoolingHttpClientConnectionManager - Connection request: [route:
{}->http://www.google.ch:80][total kept alive: 0; route allocated: 0 of
2; total allocated: 0 of 20]
[DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id:
0][route: {}->http://www.google.ch:80][total kept alive: 0; route
allocated: 1 of 2; total allocated: 1 of 20]
[DEBUG] MainClientExec - Opening connection {}->http://www.google.ch:80
[DEBUG] HttpClientConnectionOperator - Connecting to
www.google.ch/173.194.113.152:80
[DEBUG] HttpClientConnectionOperator - Connection established
192.168.42.101:39266<->173.194.113.152:80
[DEBUG] MainClientExec - Executing request POST / HTTP/1.1
[DEBUG] MainClientExec - Target auth state: UNCHALLENGED
[DEBUG] MainClientExec - Proxy auth state: UNCHALLENGED
[DEBUG] headers - http-outgoing-0 >> POST / HTTP/1.1
[DEBUG] headers - http-outgoing-0 >> Content-Length: 5
[DEBUG] headers - http-outgoing-0 >> Content-Type: text/plain;
charset=ISO-8859-1
[DEBUG] headers - http-outgoing-0 >> Host: www.google.ch
[DEBUG] headers - http-outgoing-0 >> Connection: Keep-Alive
[DEBUG] headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.3.3
(java 1.5)
[DEBUG] headers - http-outgoing-0 >> Expect: 100-continue
[DEBUG] headers - http-outgoing-0 >> Accept-Encoding: gzip,deflate
[DEBUG] headers - http-outgoing-0 << HTTP/1.1 100 Continue
[DEBUG] headers - http-outgoing-0 << HTTP/1.1 405 Method Not Allowed
[DEBUG] headers - http-outgoing-0 << Content-Type: text/html;
charset=UTF-8
[DEBUG] headers - http-outgoing-0 << Content-Length: 1453
[DEBUG] headers - http-outgoing-0 << Allow: GET, HEAD
[DEBUG] headers - http-outgoing-0 << Alternate-Protocol: 80:quic
[DEBUG] headers - http-outgoing-0 << Date: Wed, 21 May 2014 13:19:01 GMT
[DEBUG] headers - http-outgoing-0 << Server: gws
[DEBUG] headers - http-outgoing-0 << X-Frame-Options: SAMEORIGIN
[DEBUG] headers - http-outgoing-0 << X-XSS-Protection: 1; mode=block
[DEBUG] MainClientExec - Connection can be kept alive indefinitely
[DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown
connection
[DEBUG] MainClientExec - Connection discarded
[DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Close
connection
[DEBUG] PoolingHttpClientConnectionManager - Connection released: [id:
0][route: {}->http://www.google.ch:80][total kept alive: 0; route
allocated: 0 of 2; total allocated: 0 of 20]
---
Oleg
Re: Expect-continue doesn't seem operative using 4.3.x builder
structures
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2014-05-21 at 08:52 -0400, Karl Wright wrote:
> Hi Oleg,
>
> A few months back, if you will recall, I ported much of ManifoldCF to use
> the HttpClient 4.3 builder structures for its various connectors.
>
> Unfortunately, one thing we'd previously fixed came unfixed when I did
> this. We have a user who has a site that is being posted to that requires
> basic auth. We were getting an exception with HttpClient 4.2 having to do
> with non-repeatable request entities. We solved that by turning on
> expect-continue.
>
> For 4.3, we still have expect-continue on, but now we are getting similar
> problems:
>
> >>>>>>
>
> Caused by: org.apache.http.client.NonRepeatableRequestException:
> Cannot retry request with a non-repeatable request entity.
> at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:208)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> >>>>>>
>
> The code used to set up HttpClient looks like this:
>
> >>>>>>
> RequestConfig.Builder requestBuilder = RequestConfig.custom()
> .setCircularRedirectsAllowed(true)
> .setSocketTimeout(socketTimeout)
> .setStaleConnectionCheckEnabled(true)
> .setExpectContinueEnabled(true)
> .setConnectTimeout(connectionTimeout)
> .setConnectionRequestTimeout(socketTimeout);
>
> HttpClientBuilder clientBuilder = HttpClients.custom()
> .setConnectionManager(connectionManager)
> .setMaxConnTotal(1)
> .disableAutomaticRetries()
> .setDefaultRequestConfig(requestBuilder.build())
> .setRedirectStrategy(new DefaultRedirectStrategy())
> .setSSLSocketFactory(myFactory)
> .setRequestExecutor(new HttpRequestExecutor(socketTimeout))
> .setDefaultSocketConfig(SocketConfig.custom()
> .setTcpNoDelay(true)
> .setSoTimeout(socketTimeout)
> .build()
> );
>
>
> if (userID != null && userID.length() > 0 && password != null)
> {
> CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
> Credentials credentials = new
> UsernamePasswordCredentials(userID, password);
> if (realm != null)
> credentialsProvider.setCredentials(new
> AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT, realm),
> credentials);
> else
> credentialsProvider.setCredentials(AuthScope.ANY, credentials);
>
> clientBuilder.setDefaultCredentialsProvider(credentialsProvider);
> }
>
> HttpClient localClient = clientBuilder.build();
> <<<<<<
>
> Wire logs show *no* expect/continue at all taking place. Can you tell
> me what we are doing wrong?
>
> Thanks,
> Karl
I see nothing wrong with your code. At the same time I executed the test
app below and got the expected behavior with regards to the
expect-continue handshaking.
---
RequestConfig requestConfig = RequestConfig.custom()
.setExpectContinueEnabled(true)
.build();
CloseableHttpClient client = HttpClients.custom()
.setDefaultRequestConfig(requestConfig)
.build();
HttpPost post = new HttpPost("http://www.google.ch/");
post.setEntity(new StringEntity("stuff", ContentType.TEXT_PLAIN));
CloseableHttpResponse response = client.execute(post);
try {
} finally {
response.close();
}
---
---
[DEBUG] RequestAddCookies - CookieSpec selected: best-match
[DEBUG] RequestAuthCache - Auth cache not set in the context
[DEBUG] PoolingHttpClientConnectionManager - Connection request: [route:
{}->http://www.google.ch:80][total kept alive: 0; route allocated: 0 of
2; total allocated: 0 of 20]
[DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id:
0][route: {}->http://www.google.ch:80][total kept alive: 0; route
allocated: 1 of 2; total allocated: 1 of 20]
[DEBUG] MainClientExec - Opening connection {}->http://www.google.ch:80
[DEBUG] HttpClientConnectionOperator - Connecting to
www.google.ch/173.194.113.152:80
[DEBUG] HttpClientConnectionOperator - Connection established
192.168.42.101:39266<->173.194.113.152:80
[DEBUG] MainClientExec - Executing request POST / HTTP/1.1
[DEBUG] MainClientExec - Target auth state: UNCHALLENGED
[DEBUG] MainClientExec - Proxy auth state: UNCHALLENGED
[DEBUG] headers - http-outgoing-0 >> POST / HTTP/1.1
[DEBUG] headers - http-outgoing-0 >> Content-Length: 5
[DEBUG] headers - http-outgoing-0 >> Content-Type: text/plain;
charset=ISO-8859-1
[DEBUG] headers - http-outgoing-0 >> Host: www.google.ch
[DEBUG] headers - http-outgoing-0 >> Connection: Keep-Alive
[DEBUG] headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/4.3.3
(java 1.5)
[DEBUG] headers - http-outgoing-0 >> Expect: 100-continue
[DEBUG] headers - http-outgoing-0 >> Accept-Encoding: gzip,deflate
[DEBUG] headers - http-outgoing-0 << HTTP/1.1 100 Continue
[DEBUG] headers - http-outgoing-0 << HTTP/1.1 405 Method Not Allowed
[DEBUG] headers - http-outgoing-0 << Content-Type: text/html;
charset=UTF-8
[DEBUG] headers - http-outgoing-0 << Content-Length: 1453
[DEBUG] headers - http-outgoing-0 << Allow: GET, HEAD
[DEBUG] headers - http-outgoing-0 << Alternate-Protocol: 80:quic
[DEBUG] headers - http-outgoing-0 << Date: Wed, 21 May 2014 13:19:01 GMT
[DEBUG] headers - http-outgoing-0 << Server: gws
[DEBUG] headers - http-outgoing-0 << X-Frame-Options: SAMEORIGIN
[DEBUG] headers - http-outgoing-0 << X-XSS-Protection: 1; mode=block
[DEBUG] MainClientExec - Connection can be kept alive indefinitely
[DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown
connection
[DEBUG] MainClientExec - Connection discarded
[DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Close
connection
[DEBUG] PoolingHttpClientConnectionManager - Connection released: [id:
0][route: {}->http://www.google.ch:80][total kept alive: 0; route
allocated: 0 of 2; total allocated: 0 of 20]
---
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org