Get response's original content-encoding

[kwin]

Jetty Version
12.1.5

Jetty Environment
Client

Java Version
21

Question
I use a Jetty HTTP Client and want to know if a response was sent with in compressed format. However the original Content-Encoding header seem to be removed by Jetty when using the compression handlers as outlined in https://jetty.org/docs/jetty/12.1/programming-guide/client/http.html#content-response.
Apache HTTPClient no longer removes the original response headers (even when decompressing the response body), compare with https://issues.apache.org/jira/browse/HTTPCLIENT-2409.

How do get this information if not exposed via Response headers in Jetty HTTP Client?

[kwin]

Seems the original response header is removed here:

jetty.project/jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/transport/HttpReceiver.java

Line 554 in adfc2e1

else if (header == HttpHeader.CONTENT_ENCODING && !seenContentEncoding)

[joakime]

You can turn off the automatic content decoding, and the header will still be seen.
Leaving you to handle the content encoding yourself.

[joakime]

Look at https://jetty.org/docs/jetty/12.1/programming-guide/client/http.html#content-response

There it details how the content decoders works, and a code snippet on how to clear the automatic content decoders.

[kwin]

I don't want to disable the automatic decompression. Any way to get info about compression while still leveraging auto decompression?

[sbordet]

You can get the headers by registering a header listener (note the singular in the method name):

httpClient.newRequest(...)
    .onResponseHeader((response, field) -> true)
    ...
    .send();

The field parameter contains the raw header field (name and value) as it arrived from the network, before the processing performed by the decoder logic.

Return true to keep the header, false to remove the header.

Documentation here:
https://jetty.org/docs/jetty/12.1/programming-guide/client/http.html#listeners

[sbordet]

Can I ask why you need all this?
Can you detail the use case you are trying to implement?
I ask because maybe there are better ways to achieve what you want, but you're not explaining why you need all this information.

[kwin]

This is mostly for exposing info for debugging purposes (the context is apache/maven-resolver#1761). We faced some issues in the past where servers behaved incorrectly and this is just to ease pointing to the error.

[sbordet]

You can wrap the default ContentDecoder.Factory instances.

The idea is to start HttpClient, then access the default decoder factories, and re-configure HttpClient with your own decoder factories that will delegate to the default ones.

In this way, you would be able to access the compressed Content.Source to count the bytes.

It is a bit clunkier than just a listener, but I think doable (I have not tried though).

[joakime]

Could we just rename the (now inaccurate) response headers instead of removing them?

From	To
Content-Encoding: gzip	X-Original-Content-Encoding: gzip
Transfer-Encoding: chunked	X-Original-Transfer-Encoding: chunked
Content-Length: 456	X-Original-Content-Length: 456

[kwin]

@joakime That would be a nice approach, although probably should be opt-in.