[jira] Commented: (SOLR-428) Restrict valid RequestHandler names

["Hoss Man (JIRA)" <ji...@apache.org>]

    [ 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.