[
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217489#comment-13217489
]
Erik Hatcher edited comment on SOLR-3161 at 2/27/12 8:32 PM:
-------------------------------------------------------------
I'll just leave this with my final thoughts on it from an architecture/elegance
perspective... paths represent resources, or perhaps rather "views" of
resources. Solr serves up sets of content, basically. Treating these views
into sets/subsets as first class "resources" HTTP-wise (HTTP being something we
really tout in Solr-land as a big fat value-add over other networking
protocols, caching/proxies/etc-wise, tried/true APIs everywhere) to me just
seems like the Right Thing to do.
Admittedly a RESTafarian, I realize it's a toematoe/tamahtoe-qt/path here, as
path/request-param, 6 of 1 down low.
As always Hoss has a way of proposing solutions to disagreements with some
poignant clarity. So I'm +1 to this approach:
{quote}
if he root goal is "make solr safer for people who don't want/expect "qt" based
requests then unless i'm overlooking something it seems like there is a far
simpler and more straightforward solution...
a) change the example solrocnfig to use handleSelect="false"
b) remove the (long ago deprecated) SolrServlet
if handleSelect == false, then the request dispatcher won't look at "/select"
requests at all (unless someone has a handler named "/select") and it would do
dispatching based on the "qt" param. currently if that's false the logic falls
throough to the SolrServlet, but if that's been removed then the request will
just fail.
So new users who copy the example will have only path based request handlers by
default, and will have to go out of their way to set handleSelect=true to get
qt based dispatching.
{quote}
I'll give this a trunk whirl myself shortly and see how it goes. I like it the
compromise and the example enforcement of "best practices".
bq. Bonus points: someone can write a DispatchingRequestHandler that can
optionally be configured with some name (such as "/select") and does nothing
put look for a "qt" param and forward to the handler with that name – but it
can have configuration options indicating which names are permitted (and any
other names would be rejected)
LOL - true true. Better that it exist as an explicit Dispatching
implementation, if you ask me, though. Ironicly, once upon a time...
[LookupDispatchAction|http://struts.apache.org/1.x/struts-extras/apidocs/org/apache/struts/actions/LookupDispatchAction.html]
Definitely +1 to including the Bonus Points into the equation too. Thanks Hoss
for stating the nicely obvious way forward.
was (Author: ehatcher):
I'll just leave this with my final thoughts on it from an
architecture/elegance perspective... paths represent resources, or perhaps
rather "views" of resources. Solr serves up sets of content, basically.
Treating these views into sets/subsets as first class "resources" HTTP-wise
(HTTP being something we really tout in Solr-land as a big fat value-add over
other networking protocols, caching/proxies/etc-wise, tried/true APIs
everywhere) to me just seems like the Right Thing to do.
Admittedly a RESTafarian, I realize it's a toematoe/tamahtoe-qt/path here, as
path/request-param, 6 of 1 down low.
As always Hoss has a way of proposing solutions to disagreements with some
poignant clarity. So I'm +1 to this approach:
{quote}
if he root goal is "make solr safer for people who don't want/expect "qt" based
requests then unless i'm overlooking something it seems like there is a far
simpler and more straightforward solution...
a) change the example solrocnfig to use handleSelect="false"
b) remove the (long ago deprecated) SolrServlet
if handleSelect == false, then the request dispatcher won't look at "/select"
requests at all (unless someone has a handler named "/select") and it would do
dispatching based on the "qt" param. currently if that's false the logic falls
throough to the SolrServlet, but if that's been removed then the request will
just fail.
So new users who copy the example will have only path based request handlers by
default, and will have to go out of their way to set handleSelect=true to get
qt based dispatching.
{quote}
I'll give this a trunk whirl myself shortly and see how it goes. I like it the
compromise and the example enforcement of "best practices".
bq. Bonus points: someone can write a DispatchingRequestHandler that can
optionally be configured with some name (such as "/select") and does nothing
put look for a "qt" param and forward to the handler with that name – but it
can have configuration options indicating which names are permitted (and any
other names would be rejected)
LOL - true true. Better that it exist as an explicit Dispatching
implementation, if you ask me, though. Ironicly, once upon a time...
[LookupDispatchAction|http://markmail.org/search/%5BSUBMIT%5D%20LookupDispatchAction%20-%20how%20to%20handle%20multiple%20%20%20%20html:submit%20%20%20%20buttons#query:[SUBMIT]%20LookupDispatchAction%20-%20how%20to%20handle%20multiple%20%20%20%20html%3Asubmit%20%20%20%20buttons+page:1+mid:6bwnfwo5ex5ae2zq+state:results]
Definitely +1 to including the Bonus Points into the equation too. Thanks Hoss
for stating the nicely obvious way forward.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
