My colleague Keith Moore (who occasionally comments on this site) shared with me one of his recent triumphs of psychic debugging. First the question:

The customer is getting an RST response from IIS and they would like to know why. Here is a fragment from a network capture that illustrates the problem. (Fragment deleted.) The full capture is available on …

Keith didn’t look at the full capture; he barely even glanced at the fragment. Because his psychic powers told him the answer:

The amount of data they are sending does not match the Content-Length header.

He goes on to explain:

If there’s unread data pending when a connection is closed, it is automatically reset.

Sure enough, the customer was uploading data to the IIS server, specifying a Content-Length of 1289 but actually sending 1291 bytes. The server stopped reading after 1289 bytes (respecting the Content-Length), and the client was upset because Hey, you forgot two bytes!

As is occasionally the case with these types of problems, the misunderstanding goes deeper than the question itself. The customer replied, “I don’t understand why the server sees 1291 bytes. If you look at the network capture, the client machine sends two frames, one of size 1289 and one of size 2. Both frames have the correct size specified in the frame header. The size of the frames is correct; I don’t see what the problem is. I mean, sure, if the first frame had a header specifying 1289 bytes and the payload contained 1291 bytes, then that would be a problem, but that is not the case here.”

The problem is not with the frames; it’s at a higher level. The client machine promised via the HTTP protocol to send 1289 bytes, and it sent 1289 bytes, and then sent two more bytes. The reset occurs because the client machine lied about how many bytes it was going to send. The frames themselves are fine; the problem is that they are the wrong frames.