jersey icon indicating copy to clipboard operation
jersey copied to clipboard

Remove `Content-Length` header when encoding response content

Open hedtkeCqse opened this issue 2 years ago • 3 comments

Hi,

as mentioned in a comment https://github.com/eclipse-ee4j/jersey/blob/21325cbb9dfe6392f1df972fb1f7f7f0275b3c85/core-common/src/main/java/org/glassfish/jersey/spi/ContentEncoder.java#L107 the Content-Length header needs to be removed when the response content is encoded as e.g. gzip because that likely changes the length.

hedtkeCqse avatar Nov 30 '23 13:11 hedtkeCqse

Hi @senivam ! it looks like this issue still happens, we are running into this right now with the most recent 2.47. we have failing request in jetty + jersey, when registering eg

@Priority(Priorities.ENTITY_CODER)
public class InvalidGzipHandlingEncoder extends ContentEncoder {
...
}
...
resourceConfig.register(new InvalidGzipHandlingEncoder(new GZipEncoder()));

because the content is compressed and for instance a 0-byte response becomes a 20 byte response due to compression header.

as @hedtkeCqse suggested, should remove the header?

Mayeb in org.glassfish.jersey.server.filter.EncodingFilter#filter at the end (where also the Content-Encoding header is set?)

thomas-k-git avatar Aug 12 '25 14:08 thomas-k-git

@thomas-k-git, thank you for the notice. I'll take a look at it.

senivam avatar Aug 13 '25 07:08 senivam

An update from my side. In our code, I guess it was our own fault, on top of the above, we also had logic that explicitly set the Content-Length header (to the wrong value) with javax.ws.rs.core.Response.ResponseBuilder#header(). So jersey obliged to our user wish (which was wrong - it was the content-length value before compression (0)). after removing that logic, it works like a charm.

sorry for the misleading hint here, disregards my comments.

cannot speak for the original reporter / unrelated to him.

cheers and thanks!

thomas-k-git avatar Aug 14 '25 06:08 thomas-k-git