If some users can’t access a web application because of timeout errors, start by drawing the big picture. From the client machine to the IIS server, what devices or servers are on the way? On an issue I worked at, there was F5 load balancer in between and it was rejecting responses from IIS because of the “Invalid Content-Length” and “Server sends too much data” errors.
In F5 logs, this is what we saw (I replaced the IP addresses with X.X.X.X):
Jul 10 08:50:30 LB.domain.com err tmm[20799]: 011f0016:3: http_process_state_prepend - Invalid action:0x10a010 Server sends too much data. serverside (X.X.X.A:443 -> X.X.X.B:55824) clientside (X.X.X.C:55824 -> X.X.X.D:443) (Server side: vip=/Common/application profile=http pool=/Common/ application server_ip=X.X.X.A)Enable “Bytes Sent” and “Bytes Received” columns in IIS Logging to record the size of the incoming requests and outgoing responses into IIS logs.
After checking IIS logs, I saw some requests and responses as big as 1.3MB!
2021-07-21 15:33:20 X.X.X.X POST /wa/1/289 – 443 –
X.X.X.X Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64) https://domain.com/wa/1 200 0 0 1313596 3802 3203 –
2021-07-21 19:02:24 X.X.X.X POST /wa/5/5 – 443 –
X.X.X.X Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64) https://domain.com/wa/5 200 0 0 400227 3805 1132 –For more information about the requests and responses, I enabled Failed Request Tracing and also collected Fiddler trace.
Cause
Load balancers may reject responses from IIS if the responses don’t comply with RFC specifications. In this case, responses were rejected because of two incompatibilities:
- Responses with 204 status code contained message body. However, RFC 7231, § 6.3.5 says:
A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.- There was a value in the Transfer-Encoding header (The value was “chunked”). RFC 7230, § 3.3.1 says:
A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content)Because of these compliance issues, the load balancer was rejecting responses coming from IIS. These issues were apparent in the Fiddler trace as well:
== Server Response ==
HTTP/1.1 204 No Content
Cache-Control: no-cache
Pragma: no-cache, no-store, must-revalidate
Transfer-Encoding: chunked <*** Not RFC compliant ***>
Expires: -1
Server: Microsoft-IIS/10.0
X-FourJs-Server: GAS/2.50
X-Powered-By: ASP.NET
<*** There shouldn't be values after this point. Not RFC compliant ***>
HTTP/1.1 204 No Content
Cache-Control: no-cache
Pragma: no-cache, no-store, must-revalidate
Transfer-Encoding: chunked
Expires: -1
Server: Microsoft-IIS/10.0
X-FourJs-Server: GAS/2.50
X-Powered-By: ASP.NET
IIS is designed to be compliant with W3C standards. However, third-party modules may alter responses and cause them to conflict with standards. This is what happened in this case. In the Failed Request Tracing log, we saw that a third-party module was adding “chunked” value to the Transfer-Encoding header.
Solution for the “Invalid Content-Length” and “Server sends too much data” errors
IIS is a carrier in this scenario. It gets the pieces from the third-party component and sends them to the client through the load balancer.
Since the issue was caused by a third-party component, you should contact their support with the findings above. It’s expected for them to make changes in their component to make it RFC compliant.
Note: If you are using F5 load balancer and running into these errors, please check their official documentation on this page.
