[ https://issues.apache.org/jira/browse/SOLR-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220095#comment-17220095 ]
Erick Erickson commented on SOLR-14945: --------------------------------------- This is explained more fully in SOLR-14844. The short form is we're setting the min gzip size to a magic number 23 in JettySolrRunnner. That corresponds to the number in the Jetty issues Samuel linked above. If Jetty changes this in future, we'll go back around this loop so we need something more robust. > Improve compressed HTTP responses handling in SolrJ > --------------------------------------------------- > > Key: SOLR-14945 > URL: https://issues.apache.org/jira/browse/SOLR-14945 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ > Reporter: Samuel García Martínez > Priority: Major > > After upgrading Jetty version to 9.4.32.v20200930 the suite > BasicHttpSolrClientTest started to fail because of how the > compression/decompression is handled on the client side. > Jetty changed its behaviour with this upgrade as part of the so for empty > responses (Content-Length: 0) with Accept-Encoding: gzip it's still returning > a Content-Encoding: gzip but with no gzip header bytes in the response. > Jetty's relevant issue: https://github.com/eclipse/jetty.project/issues/4824 > Jetty's relevant code changes: > https://github.com/eclipse/jetty.project/commit/d58da0f7d2e30c732f52a38feaba2974e299bf70#diff-e175032f6f83c7d41fb7bc1a66187f5aR232 > Interceptors should be removed and BasicHttpSolrClient should use Apache > HttpClient's provided processors decompress the HTTP responses. -- 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