[ 
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692513#comment-16692513
 ] 

Joel Bernstein edited comment on SOLR-11501 at 11/20/18 1:17 AM:
-----------------------------------------------------------------

I'd like to revisit the reasoning behind this ticket and consider reverting. In 
the description of the ticket it says:

"Solr should not parse local-params (and thus be able to switch the query 
parser) in certain circumstances. "

1) What is the reasoning behind this statement?

2) Why are we breaking backcompat like this in a minor release?


was (Author: joel.bernstein):
I'd like to revisit the reasoning behind this ticket and consider reverting. In 
the description of the ticket it says:

"Solr should not parse local-params (and thus be able to switch the query 
parser) in certain circumstances. "

1) What is the reasoning behind this statement?

2) Why are we breaking backcompat like this in minor release?

> 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