[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278094#comment-13278094 ]
Hoss Man commented on SOLR-3161: -------------------------------- bq. It's caused enough problems for our tests - and it will cause a number of people issues while trying to upgrade. I think we should leave the ability to use "qt" enabled by default. A number of people have expressed the that they find it useful. Agreed -- I see no advantage in changing the _default_ behavior when "handleSelect" isn't specified at all in the solrconfig.xml (specificly: [this change to SolrRequestParser|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java?r1=1328798&r2=1328797&pathrev=1328798] that was 1/2 of what Dawid reverted) because it causes pain on upgrade (using existing configs) w/o any obvious value that i see. I do however think the spirit of what David is proposing is a good idea: the _example_ configs that we ship should have handleSelect="false" with a comment explaining what that means, and encouraging people to use path based request handlers instead of setting it to true. That said: i don't think the comments added in [the other 1/2 of that commit|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/solr/conf/solrconfig.xml?r1=1328798&r2=1328797&pathrev=1328798] are really the best way to go, because they are only meaningful to someone who upgrades -- not to a new user looking at the config. Those comments provides no education about handleSelect (and the tradeoffs of using it) to anyone (old user or new). I would suggest as an alternative something like... {noformat} <!-- Request Dispatcher This section contains instructions for how the SolrDispatchFilter should behave when processing requests for this SolrCore. handleSelect is a legacy option that affects the behavior of requests such as /select?qt=XXX handleSelect="true" will cause the SolrDispatchFilter to process the request and dispatch the query to a handler specified by the "qt" param handleSelect="false" will cause the SolrDispatchFilter to ignore "/select" requests, resulting in a 404 unless a handler is explicitly registered with the name "/select" handleSelect="true" is not recommended for new users, but is the default for backwards compatibility --> <requestDispatcher handleSelect="false" > {noformat} ...and later on... {noformat} <!-- Request Handlers http://wiki.apache.org/solr/SolrRequestHandler Incoming queries will be dispatched to a specific handler by name based on the path specified in the request. If handleSelect="true" has been specified in the requestDispatcher, then handlers using names without a leading '/' can be accessed with: http://host/app/[core/]select?qt=name If handleSelect="true" and a /select request is processed with out a qt param specified, then the requestHandler that declares default="true" will be used. If a Request Handler is declared with startup="lazy", then it will not be initialized until the first request that uses it. --> {noformat} > 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