[
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215827#comment-13215827
]
Erik Hatcher edited comment on SOLR-3161 at 2/24/12 7:18 PM:
-------------------------------------------------------------
How about we just get rid of "qt" altogether and make everything be path-based?
Internally, request handlers can be defined with a "rh_name" but it'll
implicitly be the path. (and if it is prefixed with a / then we'll just leave
it as it works now as a path, of course). In other words, we can be flexible
about whether the name itself has a / in front or not, but same effect either
way. Is there a need to continue to support qt at all? Why? And in the
example configuration we can simply register a "select" request handler (that
would be mapped to /select).
I concur, no need to have a default setting... /select can be defined and used,
otherwise only the request handlers defined can be used.
was (Author: ehatcher):
How about we just get rid of "qt" altogether and make everything be
path-based? Internally, request handlers can be defined with a "rh_name" and
but it'll implicitly be the path. (and if it is prefixed with a / then we'll
just leave it as it works now as a path, of course). In other words, we can be
flexible about whether the name itself has a / in front or not, but same effect
either way. Is there a need to continue to support qt at all? Why? And in
the example configuration we can simply register a "select" request handler
(that would be mapped to /select).
I concur, no need to have a default setting... /select can be defined and used,
otherwise only the request handlers defined can be used.
> Use of 'qt' should be restricted to searching and should not start with a '/'
> -----------------------------------------------------------------------------
>
> Key: SOLR-3161
> URL: https://issues.apache.org/jira/browse/SOLR-3161
> Project: Solr
> Issue Type: Improvement
> Components: search, web gui
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 3.6, 4.0
>
>
> I haven't yet looked at the code involved for suggestions here; I'm speaking
> based on how I think things should work and not work, based on intuitiveness
> and security. In general I feel it is best practice to use '/' leading
> request handler names and not use "qt", but I don't hate it enough when used
> in limited (search-only) circumstances to propose its demise. But if someone
> proposes its deprecation that then I am +1 for that.
> Here is my proposal:
> Solr should error if the parameter "qt" is supplied with a leading '/'.
> (trunk only)
> Solr should only honor "qt" if the target request handler extends
> solr.SearchHandler.
> The new admin UI should only use 'qt' when it has to. For the query screen,
> it could present a little pop-up menu of handlers to choose from, including
> "/select?qt=mycustom" for handlers that aren't named with a leading '/'. This
> choice should be positioned at the top.
> And before I forget, me or someone should investigate if there are any
> similar security problems with the shards.qt parameter. Perhaps shards.qt can
> abide by the same rules outlined above.
> Does anyone foresee any problems with this proposal?
> On a related subject, I think the notion of a default request handler is bad
> - the default="true" thing. Honestly I'm not sure what it does, since I
> noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'.
> Assuming it doesn't do anything useful anymore, I think it would be clearer
> to use <requestHandler name="/select" class="solr.SearchHandler"> instead of
> what's there now. The delta is to put the leading '/' on this request handler
> name, and remove the "default" attribute.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
