[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495132#comment-14495132
]
Gregory Chanan commented on SOLR-6625:
--------------------------------------
[~ichattopadhyaya] thanks for posting the patch. As far as I can tell, this
replaces our own interface/abstract class for callbacks with an
HttpRequestInterceptor. That seems reasonable, but there are a few issues
discussed on this JIRA that don't seem addressed. A somewhat comprehensive
list:
1. How is configuration handled? Is it the responsibility of the
authentication layer to specify the HttpRequestInterceptor to use for all
requests?
2. There is some question about passing in SolrRequests (client) vs
SolrQueryRequests (server). Presumably the authentication layer needs to
operate on the client side (often the authentication requirements will be the
same), but what are you supposed to do with the SolrQueryRequest? You've sort
of hidden it by putting it in the context, but that seems fragile; we should
have our own Context that makes clear what is available, but if you pull in
SolrQueryRequest, then clients need access to server data structures, which
isn't ideal. Perhaps the right thing to do is split up client vs server
interceptors?
3. Can the request interceptor do everything our own callback can do? There
are sample tests in the patch which add cookies, modify the URL, etc. It would
be good to see those tests with the new implementation
4. How do you check that we actually pass the correct information to the
interceptor? [~steff1193] described this above; what if someone adds another
httpclient.execute call tomorrow and doesn't pass the SolrRequest object?
We'll never know, so relying on the HttpRequestInterceptor didn't really help
us (it automatically dispatches but doesn't check that it has all the info it
needs to dispatch). It just limits us to an interface we don't control. We
need some way of enforcing the property that every call to httpclient has the
information we need.
> 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,
> SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch,
> SOLR-6625_r1654079.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: [email protected]
For additional commands, e-mail: [email protected]
