[jira] [Comment Edited] (SOLR-13014) URI Too Long with large streaming expressions in SolrJ
[
https://issues.apache.org/jira/browse/SOLR-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16719171#comment-16719171
]
Jan Høydahl edited comment on SOLR-13014 at 12/12/18 6:14 PM:
--
Thanks Joel. Are you aware of other expressions that are likely to become too
large, e.g. because they can take a query string?
was (Author: janhoy):
Thanks Joel
> URI Too Long with large streaming expressions in SolrJ
> --
>
> Key: SOLR-13014
> URL: https://issues.apache.org/jira/browse/SOLR-13014
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, streaming expressions
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For very large expressions (e.g. with a complex search string) we'll hit the
> max HTTP GET limit since SolrJ does not enforce POST for all expressions.
> This goes at least for {{FacetStream}}, {{StatsStream}} and
> {{TimeSeriesStream}}, and I'll link a Pull Request fixing these three.
> Here is an example of a stack trace when using TimeSeriesStream with a very
> large expression: [https://gist.github.com/ea626cf1ec579daaf253aeb805d1532c]
> The fix is simply to use {{new QueryRequest(parameters,
> SolrRequest.METHOD.POST);}} to explicitly force POST.
> See also solr-user thread
> [http://lucene.472066.n3.nabble.com/Streaming-Expressions-GET-vs-POST-td4415044.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13014) URI Too Long with large streaming expressions in SolrJ
[
https://issues.apache.org/jira/browse/SOLR-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698643#comment-16698643
]
Jan Høydahl edited comment on SOLR-13014 at 11/26/18 9:08 AM:
--
Would be tempting to just make the default Method of {{QueryRequest}} be POST
instead of GET. We've seen many similar bugs lately regarding GET size limit.
I'm just worried that {{AuthorizationPlugins}} may start rejecting legitimate
requests if they switch from GET to POST...
Or we could make a {{StreamRequest extends QueryRequest}} to use in all
{{Stream}}s.
To support Authorization for streaming we'll probably have to do other changes
as well, and not rely on HTTP verb to determine read/write. Would need to let
each Expression class declare whether it can modify state or not, and then plug
Authorization into that.
was (Author: janhoy):
Would be tempting to just make the default Method of {{QueryRequest}} be POST
instead of GET. We've seen many similar bugs lately regarding GET size limit.
I'm just worried that {{AuthorizationPlugins}} may start rejecting legitimate
requests if they switch from GET to POST...
> URI Too Long with large streaming expressions in SolrJ
> --
>
> Key: SOLR-13014
> URL: https://issues.apache.org/jira/browse/SOLR-13014
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, streaming expressions
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For very large expressions (e.g. with a complex search string) we'll hit the
> max HTTP GET limit since SolrJ does not enforce POST for all expressions.
> This goes at least for {{FacetStream}}, {{StatsStream}} and
> {{TimeSeriesStream}}, and I'll link a Pull Request fixing these three.
> Here is an example of a stack trace when using TimeSeriesStream with a very
> large expression: [https://gist.github.com/ea626cf1ec579daaf253aeb805d1532c]
> The fix is simply to use {{new QueryRequest(parameters,
> SolrRequest.METHOD.POST);}} to explicitly force POST.
> See also solr-user thread
> [http://lucene.472066.n3.nabble.com/Streaming-Expressions-GET-vs-POST-td4415044.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
