[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326592#comment-16326592
]
David Smiley commented on SOLR-11501:
-------------------------------------
[~tuky] you are correct, my bad. I looked at this closer and the Solr Ref
Guide and I want to clean up some things about this stuff. The edismax page
doesn't need its last section which is about _val_ and _query_ because this is
a feature of the standard query parser that it _inherits_. I think edismax docs
should mention it inherits this though, and should have better docs on {{uf}}
so it's clear how it's handled. I forgot to do that. The standard query parser
page should mention _val_ and _query_ but say deprecated in favor of
local-params syntax (with a link). BTW I don't like the term "standard query
parser"; I'd rather say "the Solr query parser" albeit {{{!solr}}} doesn't
exist though it should the moment it came to exist to bifurcate from Lucene's
classic QP. But it's too much change to quite do that here!
I'll post a patch in a bit... I suppose I could create a new issue but it's
just docs.
> Depending on the parser, QParser should not parse local-params
> --------------------------------------------------------------
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}&qq=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]