[
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259399#comment-13259399
]
David Smiley commented on SOLR-3161:
------------------------------------
I swear I ran the tests before committing (which passed) -- I'll try and be
more careful somehow. I used the IntelliJ test runner for all of Solr and I
see it fails now. Strange.
So the tests that failed did so because of one test config file
solrconfig-tlog.xml doesn't have a handleSelect=true on it nor "/select"
registered, just the old "StandardRequestHandler" registered as the name
"standard". This file is so short at ~26 lines of XML from <config> to
</config>, it clearly was never copied from a Solr example solrconfig.xml.
Interestingly there are some other configuration files done similarly but they
have yet to pose a problem. I looked into why and the reason is that those
tests use embedded Solr and thus the default handler is looked up as such via
core.getRequestHandler(null) no matter what its name actually is.
No test has failed because it wanted to use "qt" but couldn't. Instead, tests
have failed regarding "/select" not working. The handleSelect option
intertwines the two which is unfortunate and unnecessary. *Here's a proposal:*
Make handleSelect do just what it's name implies -- handles "/select" when
"/select" isn't registered. And this is, in effect, to register the default
handler under an alias of "/select". The 'qt' feature should be a distinctly
separate option, and IMO disabled by default.
> 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
>
> Attachments: SOLR-3161-disable-qt-by-default.patch,
> SOLR-3161-dispatching-request-handler.patch,
> SOLR-3161-dispatching-request-handler.patch,
> SOLR-3161_limit_qt=_____to_refer_to_SearchHandlers,_and_shards_qt_likewise.patch,
> SOLR-3161_make_the_slash-select_request_handler_the_default.patch
>
>
> 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
