[
https://issues.apache.org/jira/browse/SOLR-14844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212045#comment-17212045
]
Samuel García Martínez commented on SOLR-14844:
-----------------------------------------------
After doing some digging it looks like Jetty changed GzipHandler behaviour
between 9.4.27 and 9.4.30.
With the .27 version, an empty response (Content-Length: 0) with
Accept-Encoding: gzip always resulted in a response with Content-Lenght: 20 but
with an empty body (I don't understand this behaviour). I tested it with:
{code:java}
curl -H 'Accept-Encoding:gzip' -vvvv
'http://127.0.0.1:53510/solr/debug/foo/select?q=test'
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 53510 (#0)
> GET /solr/debug/foo/select?q=test HTTP/1.1
> Host: 127.0.0.1:53510
> User-Agent: curl/7.64.1
> Accept: */*
> Accept-Encoding:gzip
>
< HTTP/1.1 200 OK
< Date: Sun, 11 Oct 2020 21:43:20 GMT
< Vary: Accept-Encoding, User-Agent
< Content-Encoding: gzip
< Content-Length: 20
< Server: Jetty(9.4.27.v20200227)
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 20)
* Closing connection 0
{code}
After testing it with the .30 version, behaviour changed. Now, for an empty
response (Content-Length: 0) it doesn't change it to Content-Length:20. The
thing now is that the GzipDecompressingEntity doesn't work properly for empty
responses and hits an EOF exception.
{code:java}
curl -H 'Accept-Encoding:gzip' -vvvv
'http://127.0.0.1:56515/solr/debug/foo/select?q=test'
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 56515 (#0)
> GET /solr/debug/foo/select?q=test HTTP/1.1
> Host: 127.0.0.1:56515
> User-Agent: curl/7.64.1
> Accept: */*
> Accept-Encoding:gzip
>
< HTTP/1.1 200 OK
< Date: Sun, 11 Oct 2020 21:54:57 GMT
< Vary: Accept-Encoding, User-Agent
< Content-Encoding: gzip
< Content-Length: 0
< Server: Jetty(9.4.30.v20200611)
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0
{code}
In my opinion, the impact of this behaviour should be minimal (or shouldn't
impact anything at all) as it only affects responses with empty bodies and as
far as I know, there is no such thing in Solr.
Do you want me to provide a patch modifying HttpClientUtils to account for
empty bodies and modify the test according to this new behaviour change from
Jetty 9.4.30?
> Upgrade Jetty to 9.4.32.v20200930
> ---------------------------------
>
> Key: SOLR-14844
> URL: https://issues.apache.org/jira/browse/SOLR-14844
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 8.6
> Reporter: Cassandra Targett
> Assignee: Erick Erickson
> Priority: Major
>
> A CVE was found in Jetty 9.4.27-9.4.29 that has some security scanning tools
> raising red flags
> ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17638]).
> Here's the Jetty issue:
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984]. It's fixed in
> 9.4.30+, so we should upgrade to that for 8.7
> -It has a simple mitigation (raise Jetty's responseHeaderSize to higher than
> requestHeaderSize), but I don't know how Solr uses Jetty well enough to a)
> know if this problem is even exploitable in Solr, or b) if the workaround
> suggested is even possible in Solr.-
> In normal Solr installs, w/o jetty optimizations, this issue is largely
> mitigated in 8.6.3: see SOLR-14896 (and linked bug fixes) for details.
--
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
