[
https://issues.apache.org/jira/browse/SOLR-7681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589011#comment-14589011
]
Ramkumar Aiyengar commented on SOLR-7681:
-----------------------------------------
Do you think these justify GET being the default? Solr can already do caching
(better than proxies since it can invalidate), and our logs can show the
parameters on POST really if needed. I am not arguing against having GET
altogether, just that if we should encourage people to use it..
Note that increasing the buffer might have perf implications, most HTTP parsers
are optimised to deal with short headers, with large amounts of data following
it if necessary -- I don't know about jetty impl though.
Alternative (more complicated) might be for us to somehow know what the limit
is (might be possible now that we know we use Jetty), have that available
through clusterstate and switch between GET and POST based on payload size. I
am not convinced myself though that this complexity is worth it..
> HttpSolrClient fails with a confusing error when a GET request is too big
> -------------------------------------------------------------------------
>
> Key: SOLR-7681
> URL: https://issues.apache.org/jira/browse/SOLR-7681
> Project: Solr
> Issue Type: Bug
> Reporter: Ramkumar Aiyengar
> Priority: Minor
>
> If a request is sent with too long an URL for GET, the Solr server responds
> as follows:
> {code}
> HTTP/1.1 413 FULL head
> Content-Length: 0
> Connection: close
> Server: Jetty(8.1.10.v20130312)
> {code}
> {{oascsi.HttpSolrServer.executeMethod}} currently in such a situation, goes
> ahead and tries to parse a {{Content-Type}} header in such a case and ends up
> with a {{SolrServerException: Error executing query}} caused by
> {{org.apache.http.ParseException: Invalid content type}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
