Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 27 Mar 2012 05:03:35 +0000 (UTC)
From: "David Smiley (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1289676525.21808.1332824616390.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1963294774.16246.1330109991301.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to
 searching and should not start with a '/'
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239186#comment-13239186 ] 

David Smiley commented on SOLR-3161:
------------------------------------

I was looking at the logs of Solr's example config, unmodified and I noticed something troubling that I haven't noticed before:
{noformat}
WARNING: [] Null Request Handler 'null':{event=firstSearcher&q=static+firstSearcher+warming+in+solrconfig.xml}
{noformat}
It turns out that the default="true" attribute on the request handler actually does something :-)  In RequestHandlers.initHandlersFromConfig() line 164 it checks this flag and registers the handler under the "" name.  QuerySenderListener.newSearcher() line 59 does a lookup of "qt" from the its configuration (e.g. firstSearcher) getting null and then calling SolrCore.execute(null,...).

Given that "/select" is referenced as a default in about a dozen places in Solr (.java source, excluding tests), it seems to me that if no request handler is marked as default then "/select" should become the default automatically (if present).  Interestingly a similar check occurs as the very last line of RequestHandlers.initHandlersFromConfig() but for a request handler named "standard" -- which seems like a very old way things used to be (seems like a candidate for updating in Solr 4 to "/select").  So I propose that if "standard" isn't found, then it tries "/select".
                
> 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
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org