[
https://issues.apache.org/jira/browse/SOLR-7681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589046#comment-14589046
]
Hoss Man commented on SOLR-7681:
--------------------------------
i don't have a strong opinion about wether SolrJ defaults to GET or POST, i was
just pointing out the advantages of GET in response to your question (aside:
Solr's caching is great, and helps at a micro level, but in my experience HTTP
caching is still very valuable at a macro level - particularly in the case of
DoS type situations)
I don't disagree with any of the points you've made, but those all address
changes in the *client* -- of which we only control *1* (solrj)
It doesn't change the fact that on the _server side_ (which is what this issue
is about) we should make the error message more useful when someone triggers
this problem from python/curl/ruby/haskell/whatever -- and i would argue it's
worth while to at least investigate increasing the limit in jetty to see if
there are any downsides, or at least figuring out a way to expose it as a
tunable _server configuration_ knob even if we decide not to increase it by
default.
> 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]
