CODEWITHSUNDEEP
iishttpresponse
Steve Crockett
Steve Crockett

Reputation: 199

Response body missing characters

I've seen this issue happen on multiple machines, using different languages and server-side environments. It seems to always be IIS, but it may be more widespread.

On slower connections, characters are occasionally missing from the response body. It happens somewhere between 25% and 50% of the time but only on certain pages, and only on a slow connection such as VPN. A refresh usually fixes the issue.

The current application in question is .NET 4 with SQL Server.

Example:

<script>
  document.write('Something');
</script>

is being received by the client as

<scrit>
  document.write('Something');
</script>

This causes the JavaScript inside the tag to instead be printed to the page, rather than executing.

Does anyone know why this occurs? Is it specific to IIS?

Upvotes: 0

Views: 802

Answers (1)

Mitch
Mitch

Reputation: 22251

Speaking generally, the problem you describe would require corruption at the HTTP layer or above, since TCP/IP has checksums, packet lengths, sequence numbers, and re-transmissions to avoid this sort of issue.

That leaves:

  • The application generating the data
  • Any intermediate filters between the application and the server
  • The HTTP server returning the data
  • Any intermediary HTTP proxies, transparent or otherwise
  • The HTTP client requesting the data
  • The user-agent interpreting the data

You can diagnose further based off of a network capture performed at the server edge, and at the client edge.

  • Examine the request made by the client at the client edge to verify that the client is making a request for the entire document, and is not relying upon cache (no Range or If-* headers).
  • If the data is correct when it leaves the server (pay particular attention to the Content-Length header and verify it is a 200 response), neither the server nor the application are at fault.
  • If the data is correct as received by the client, you can rule out intermediary proxies.
  • If there is still an issue, it is a user-agent issue

If I had to psychically debug such a problem, I would look first at the application to ensure it is generating the correct document, then assume some interloper is modifying the data in transit. (Some HTTP proxy for wan-acceleration, aggressive caching, virus scanning, etc...) I might also assume some browser plugin or ad blocker is modifying the response after it is received.

I would not, however, assume it is the HTTP server without very strong evidence. If corruption is detected on the client, but not the server, I might disable TCP Offload and look for an updated NIC Driver.

Upvotes: 1

Related Questions