[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory Chanan updated SOLR-6625:
---------------------------------
Attachment: SOLR-6625.patch
Put up a review request: https://reviews.apache.org/r/28826
Need patch allows the callback to throw an IOException; this allows the calling
code to do something reasonable in error cases, i.e. if the callback makes an
HttpRequest, the code in SolrDispatchFilter will print a good error message
about it failing when trying to forward requests if it actually fails.
The only part I'm hesitant about here is the code to generate a SolrRequest if
one doesn't exist (in SolrCLI, SolrDipsatchFilter). This seems like a decent
amount of complexity for little gain compared to just passing null. For my
case, in the SolrDispatchFilter, I need to get some information from the
SolrQueryRequest or HttpServletRequest (basically, the authenticated user).
But passing in either of those classes doesn't seem like a good idea, because
those are both really server-side data structures and the
HttpClientRequestCallback is client side. We could have a different interface
for the server-side stuff, but that doesn't seem less complex than generating a
new SolrRequest. One alternative would be to pass a SolrParams or Map (i.e.
SolrQueryRequest.getContext()) as another parameter, call it context, and make
it clear from the documentation it is only useful on forwarded requests and can
be ignored for clients. That would allow us to remove the code for
HttpHead/HttpDelete support in SolrRequests.
Anyway, that's my thinking right now, any feedback would be appreciated.
> HttpClient callback in HttpSolrServer
> -------------------------------------
>
> Key: SOLR-6625
> URL: https://issues.apache.org/jira/browse/SOLR-6625
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Gregory Chanan
> Assignee: Gregory Chanan
> Priority: Minor
> Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
> SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch
>
>
> Some of our setups use Solr in a SPNego/kerberos setup (we've done this by
> adding our own filters to the web.xml). We have an issue in that SPNego
> requires a negotiation step, but some HttpSolrServer requests are not
> repeatable, notably the PUT/POST requests. So, what happens is,
> HttpSolrServer sends the requests, the server responds with a negotiation
> request, and the request fails because the request is not repeatable. We've
> modified our code to send a repeatable request beforehand in these cases.
> It would be nicer if HttpSolrServer provided a pre/post callback when it was
> making an httpclient request. This would allow administrators to make
> changes to the request for authentication purposes, and would allow users to
> make per-request changes to the httpclient calls (i.e. modify httpclient
> requestconfig to modify the timeout on a per-request basis).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
