[ 
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]

Reply via email to