title: Jersey response: don't set Content-Length header if Transfer-Encoding is already set
body: <p>I have a Jersey-Application that proxies a request to an internal application, which should be out of direct access.</p>
  
  <pre><code>@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;
  </code></pre>
  
  <p>In the response, that comes from the internal application, there's the <code>Transfer-Encoding = chunked</code> header set. This is alright so far.</p>
  
  <p>Now, the response that is sent to the client also contains the <code>Content-Length</code> 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. </p>
  
  <p>The <code>Content-Length</code> header causes the client to not interpret the response correctly, as there should be either  <code>Content-Length</code> or <code>Transfer-Encoding</code> set, as stated <a href="https://en.wikipedia.org/wiki/Chunked_transfer_encoding" rel="nofollow">here</a>.</p>
  
  <p>How can I prevent Jersey from setting the <code>Content-Length</code> header, if I already have the Transfer-Encoding set?</p>