[
https://issues.apache.org/jira/browse/SOLR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549657
]
Hoss Man commented on SOLR-428:
-------------------------------
first: just to clarify the restriction is that a handler name can't start with
"/@" right?
second: why do we need this restriction? why does the core name need to be
indicated with an "@" symbol at all?
my understanding from the wiki docs i've seen is that if (and only if) you have
a multicore.xml then MultiCore support is active, and if MultiCore support is
active, then every URL path except that "adminPath" must start with an
"@corename" ... so why not just say that if you MultiCore support is active,
and if a request comes in for a URL whose path doesn't match the adminPath the
first "dir" in the URL path is the "corename" (no @). If MultiCore is not
active then regular handler name resolution applies.
the only restriction in this case being that core names can't contain "/" ...
but request handler names can be anything you want (like they are today).
* doesn't impact existing (single core) users
* simpler urls for multicore users
?
> Restrict valid RequestHandler names
> -----------------------------------
>
> Key: SOLR-428
> URL: https://issues.apache.org/jira/browse/SOLR-428
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3
> Reporter: Ryan McKinley
> Priority: Minor
> Attachments: SOLR-428-HanderNameRestriction.patch
>
>
> In SOLR-350, we added support for multiple cores. To access each core, you
> send a request to:
> http://host:port/context/@core0/handlerpath - uses core0
> http://host:port/context/@core1/handlerpath - uses core1
> This is fine unless a hander is registered to the a name that starts with '@'
> I think we should make a rule that the 1st character has to be a letter or
> digit. This will give us room to treat other leading punctuation as a key
> token.
> Perhaps it is not fair to add this restriction after 1.2, but it is
> (hopefully) a rare case so not a big deal. I guess we could add a
> configurable flag to not check this condition...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
