[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17158689#comment-17158689
]
Mikhail Khludnev commented on SOLR-11501:
-
ok. Regarding [^SOLR-11501-breaker.patch], {{defType=edismax&uf=*
_query_&q={!lucene df=text_sw}(gigabyte)}} worked before, because edismax
didn't attempted to parse local params here, parser was switched early, and
{{QParser.prarseLocalParams()}} just stripped the prefix.
Now, edismax tries to parse it and fails. Followup SOLR-14557.
> 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
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152100#comment-17152100
]
Mikhail Khludnev commented on SOLR-11501:
-
Attached two tests, both are green before this commit. The one with enclosed
parenthesis {{uf=* _query_&q={!lucene df=text_sw}(gigabyte)}} fails after this
commit. (Note: this commit and reproducer was found by [~anatolii_siuniaev]).
Interesting there's a straightforward fix attached to SOLR-14557, however it
fixes lucene parser jj grammar.
> 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
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
