Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 24 Feb 2012 22:07:48 +0000 (UTC)
From: "David Smiley (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <2043152685.17152.1330121268830.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=13215982#comment-13215982 ] 

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

bq. I see the argument for an internal only "rh" parameter, but still seems it shouldn't be necessary to even have that, such that we could dispatch to a request handler internally directly without having to specify qt/rh/requestHandler as a query parameter. How we do that, I'm not sure yet though.

It seems unavoidable that an internal request handler parameter name be used for the config file in these couple places.  I don't think that's a big deal and I think it can be retained in a way that still brings some overall code clarity, security, and even lines-of-code reduction.  And I guess Yonik's right about keeping the old name, even though it's a bad one.
                
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org