Hmm, quite some ideas there :-)
One step at a time, though I'm not sure I agree with the destination you
fantasized about. Would the next step "just" be a matter of splitting out
the parts of SolrDispatchFilter that are not very filter-y and creating a
SolrServlet from that? Don't need to retain
Converting Solr to a servlet, or even a query servlet, an update servlet
and an admin servlet because those are really very separate operations has
been on my mind for a long time. The overlap among those operations is all
in things like authentication or tracing that should be reusable
ServletFilt
I suspect the choice of a ServletFilter vs Servlet was done for reasons
that might have made sense forever-ago. It has always been weird. Does it
still make sense? Maybe Hossman remembers.
Why I'm bringing this up:
I heard of HTTP 404 responses coming from a Solr server I run, but didn't
see th
Thanks Houston.
FYI: I tried to reproduce the issue in my environment (Solr 9.5.0), using the
Curl request in SOLR-17417, but I could not, possibly because the
authentication configuration has "blockUnknown":true
I applied the patch anyways, to be on the safe side.
Isabelle Giguère
Computatio
With the last merge of URL options we will be able to proceed and further
simplify the CLI classes, especially in the URL composition that has been quite
error prone.
I'd like to share the last migration that affects the -i option. For that you
can have a look in the proposed changes of
https:
Officially, such information would be in our "major changes in" Solr Ref
Guide pages. It was probably a working/temporary one useful as we
approached 9.0. After all, it's way easier to edit a wiki page than to do
all the steps involved in updating our Ref Guide or any other part of our
Git repo.
I think this wiki page is rather out of date, and maybe has served it's
purpose? Do we want to maintain it?
https://cwiki.apache.org/confluence/display/SOLR/Deprecations
I think it came out of the last big effort to deprecate stuff.
Eric
