Problem with Content-Length header

is there a transfer-encoding header instead?

It isn't default behavior to strip out the content-length header, but it can be accomplished. In the http profile assigned to the virtual server, is anything in the 'Request Header Erase' section? Any irules assigned to the virtual server?

This is what I get. I just have regular irules for redirects and thats about it. curl -I -L https:// HTTP/1.1 301 Moved Permanently Date: Thu, 19 Jun 2014 18:29:43 GMT Server: Apache/2.2.0 (Fedora) Location: Connection: close Content-Type: text/html; charset=iso-8859-1 Transfer-Encoding: chunked

HTTP/1.1 302 Found Proxy-Connection: Keep-Alive Connection: Keep-Alive Content-Length: 0 Via: 1.0 PROXY1 Location: https:// Server: BigIP

HTTP/1.1 200 OK Date: Thu, 19 Jun 2014 18:29:44 GMT Server: Apache/2.2.0 (Fedora) X-Powered-By: PHP/5.1.6 Set-Cookie: LTCPSESSID=471eart91cnkor1pisrk848233; httpOnly Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked

Alright, I see it. Transfer Encoding is enabled. I guess this is done on the server level right?

The LTM could be doing it if your have Rechunk selected in the HTTP profile under Response Chunking. If it is set to Preserve, Selective or Unchunk, then the server is doing it.

Thanks alot. Its not selected as Chunking, so the server would be doing it.

I am still getting the same issue and devs are pushing back saying everything on the server is fine. Is there any other place on the F5 which may be causing this?

If I may add, assuming the backend traffic is unencrypted you should be able to insert a tcpdump capture and verify for certain if the server is sending the header.

tcpdump -lnni 0.0 -Xs0 host [IP of web server]