The Minority Report

From The Old New Thing we learn about IIS sending a RST response due to a bad Content-Length header. I’m sure that I don’t have to tell you that a RST response is contained in the TCP header and I’m equally sure that I don’t have to tell you that the Content-Length is sent in the HTTP headers.

Now at the time that I took my certifications, I often wondered why I had to memorize the stupid OSI model^W. It seemed to figure prominently in different testing levels (even though the TCP/IP model is slightly different then the OSI Model, the principles are the same).

How is the Content-Length transported? HTTP right? What layer is HTTP^W? Application layer.

How is the RST response transported? TCP… What layer is TCP^W? Transport layer.

Why is this important? Because as shown on Raymond’s blog entry, knowing the proper layers of the various protocols quickly and easily debugged the IIS problem for the customer. I can’t tell you how often I have sat down with a pad of paper and worked out the problem using the OSI model and how quickly this helped resolve issues. Something that I thought was stupid and hard to memorize (at the time) seems to crop up fairly frequently in day to day Network Administration and Web Development/Programming.

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.

The Old New Thing : Guest TCP psychic debugging: Why the remote server keeps RSTing the connection