You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jason Gerlowski (JIRA)" <ji...@apache.org> on 2019/04/07 16:15:00 UTC

[jira] [Commented] (SOLR-13270) SolrJ does not send "Expect: 100-continue" header

    [ https://issues.apache.org/jira/browse/SOLR-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811918#comment-16811918 ] 

Jason Gerlowski commented on SOLR-13270:
----------------------------------------

Thinking about this again this morning.  I think there's a few snags that weren't apparent at first.

As best as I can tell, _all_ HttpClient's have a RequestConfig object that they fall back to as a default.  That is, even if the user doesn't explicitly specify one when creating the HttpClient, the client still has a RequestConfig.  So we can't do the simple solution here of "always using the RequestConfig on the client, if it exists".  Further complicating things, HttpClient doesn't provide any accessor for getting at the RequestConfig.  So even if we knew a user wanted to use the RequestConfig attached to a given HttpClient, we couldn't do anything fancy like calling {{RequestConfig.copy}} and tweaking particular settings.

(I'm not an expert on HttpComponent stuff.  Happy to take correction if anything above is wrong.)

We do still have a few options though.  The best one probably is to add a setter on our SolrClientBuilders that controls whether or not we override RequestConfig.  It would set a flag, and based on this, HttpSolrClient could avoid calling {{HttpClientUtils.createDefaultRequestConfigBuilder}}.  This has some downsides: what happens when RequestConfig invalidates some other SolrClient settings (e.g. read timeout), what happens when a user sets this flag but doesn't provide a HttpClient, etc.  But a lot of these issues can be minimized by advertising the setter as an "expert-level" option, and making the issues very clear in the Javadocs.  It's not elegant, but it'll get the job done.

I'll upload and test out a patch with this change.  If no one has any concerns with the approach, I'll go forward with it soon.

> SolrJ does not send "Expect: 100-continue" header
> -------------------------------------------------
>
>                 Key: SOLR-13270
>                 URL: https://issues.apache.org/jira/browse/SOLR-13270
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrJ
>    Affects Versions: 7.7
>            Reporter: Erlend Garåsen
>            Assignee: Jason Gerlowski
>            Priority: Major
>
> SolrJ does not set the "Expect: 100-continue" header, even though it's configured in HttpClient:
> {code:java}
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
> A HttpClient developer has reviewed the code and says we're setting up
>  the client correctly, so we have a reason to believe there is a bug in
>  SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
>  https://issues.apache.org/jira/browse/CONNECTORS-1564
> The problem can be reproduced by building and running the following small Maven project:
> [http://folk.uio.no/erlendfg/solr/missing-header.zip]
> The application runs SolrJ code where the header does not show up and HttpClient code where the header is present.
>  
> {code:java}
> HttpClientBuilder builder = HttpClients.custom();
> // This should add an Expect: 100-continue header:
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
> HttpClient httpClient = builder.build();
> // Start Solr and create a core named "test".
> String baseUrl = "http://localhost:8983/solr/test";
> // Test using SolrJ — no expect 100 header
> HttpSolrClient client = new HttpSolrClient.Builder()
>   .withHttpClient(httpClient)
>   .withBaseSolrUrl(baseUrl).build();
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> client.query(query);
> // Test using HttpClient directly — expect 100 header shows up:
> HttpPost httpPost = new HttpPost(baseUrl);
> HttpEntity entity = new InputStreamEntity(new ByteArrayInputStream("test".getBytes()));
> httpPost.setEntity(entity);
> httpClient.execute(httpPost);
> {code}
> When using the last HttpClient test, the expect 100 header appears in missing-header.log:
> {noformat}
> http-outgoing-1 >> Expect: 100-continue{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org