David Smiley created SOLR-18470:
-----------------------------------
Summary: Limit collection handlers' scope to URL path
Key: SOLR-18470
URL: https://issues.apache.org/jira/browse/SOLR-18470
Project: Solr
Issue Type: Improvement
Reporter: David Smiley
The URL path should govern the data scope of a collection/core handler request.
Inside Solr, this should be a first class SolrQueryRequest characteristic. It
doesn't exist today; getPath() isn't it.
A request to _collection_ "collection1" at /solr/collection1/handler implies
that the scope is to the collection, not to whatever core handles it. If
that's nonsensical for a given handler (only the handler itself can judge this)
and no other parameter further specifies a specific core, then the client
should get an HTTP 400. This may be a change to perhaps certain admin handlers
that operate on the core/node serving the request.
Note the URL path may be an alias to multiple collections or a comma separated
list, and thus the resolved result is a set of collections. Perhaps only
SearchHandler can reasonably respond to multi-collection, and /update in
certain cases (e.g. time routed aliases).
It's acceptable for additional parameters, e.g. "shards" to imply a _subset_ of
the path scope.
The principle idea of this issue should apply to a core in the path... but it
may be too much scope: A request to a _core_ "core1" at /solr/core1/handler
implies that the scope is to the core. I think all core handlers can suitably
interpret this. This is a change to how SearchHandler works in SolrCloud mode,
which will search the whole collection. Perhaps /update should fail if an
update doesn't belong locally -- on princiiple but admittedly maybe not worth
doing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
