You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2026/10/23 05:06:00 UTC
[jira] [Updated] (SOLR-18446) Remove "collection" param routing support in HttpSolrCall
[ https://issues.apache.org/jira/browse/SOLR-18446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated SOLR-18446:
----------------------------------
Labels: pull-request-available (was: )
> Remove "collection" param routing support in HttpSolrCall
> ---------------------------------------------------------
>
> Key: SOLR-18446
> URL: https://issues.apache.org/jira/browse/SOLR-18446
> Project: Solr
> Issue Type: Improvement
> Components: Server
> Reporter: David Smiley
> Priority: Blocker
> Labels: pull-request-available
> Fix For: main(11.0)
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The URL path alone should govern which collection receives a collection-scoped request. Node level APIs (e.g. admin) don't count here. Consequently, the "collection" parameter should be removed or altered in semantics from the present day.
> It'd be harmless if the collection param were to assist in disambiguating a core name in the path, if we want that, as that prevents a 404.
> It'd be harmless if the collection param disambiguated multiple possibilities if the path implied more than one (i.e. was an alias to multiple collections or was comma delimited).
> It's acknowledged and out-of-scope that there are parameters like "shards" affecting how a handler (e.g. SearchHandler) dispatch distributed work. The scope of the current ticket is basically HttpSolrCall resolving to a "core" locally or remotely.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org