lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
Date Mon, 12 Mar 2012 14:02:40 GMT


Erik Hatcher commented on SOLR-3161:

bq. It's not clear... do these proposals eliminate the possibility of using qt=/myhandler?
I'm not sure we should be removing functionality that many have found useful.

My DispatchingRequestHandler currently (but only as a first draft) handles /-prefixed handlers
to dispatch to them.  But *only* if they are instanceof SearchHandler.  Without DispatchingRequestHandler,
and handleSelect=false, no qt dispatching is possible.

bq. edit: a quick look at the patch suggests that (after enabling qt) that leading-slash named
handlers will still be accessible via qt - but I couldn't discern the final intention from
the various comments in this issue.

Again, yes, currently, but only if it is a SearchHandler.  There's a TODO in there to consider
eliminate dispatching to /-prefixed handlers.  I'm +1 on that.  But it could be made even
more flexible such that a list of allowed handlers is provided, or a regex pattern, or ...
whatever.  I just like that the crazy dispatching logic is moved out of SolrDispatchFilter
and simplified, making it entirely up to the designer of the configuration to determine whether
to wire in the DispatchingRequestHandler as /select or not.  I'd generally prefer not, leaving
everything as /-prefixed handlers that can only be dispatched to directly with no qt magic
capability whatsoever.
> Use of 'qt' should be restricted to searching and should not start with a '/'
> -----------------------------------------------------------------------------
>                 Key: SOLR-3161
>                 URL:
>             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,
> 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
> 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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message