I have a Jersey-Application that proxies a request to an internal application, which should be out of direct access.
@GET
@Path("/path")
public static Response get(
@Context UriInfo uriinfo,
@Context HttpHeaders httpHeaders,
byte[] body
) throws Exception{
//call the internal application
Response response = get(url, uriinfo, httpHeaders, body, HttpMethod.GET);
ResponseBuilder rb = Response.
status(response.getStatusCode()).
entity(response.getResponseStream());
//set all headers from response
for(header : response.getResponseHeaders()){
rb.header(...);
}
Response r = rb.build();
//checking headers here, does NOT contain any Content-Length header
return r;
In the response, that comes from the internal application, there's the Transfer-Encoding = chunked header set. This is alright so far.
Now, the response that is sent to the client also contains the Content-Length header set, presumably by Jersey itself on the outgoing response. When I check the headers before I sent them to the client, all headers are set correctly like in the response from the internal app.
The Content-Length header causes the client to not interpret the response correctly, as there should be either Content-Length or Transfer-Encoding set, as stated here.
How can I prevent Jersey from setting the Content-Length header, if I already have the Transfer-Encoding set?
