[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
