The Random House Unabridged Dictionary defines post haste as "with the greatest possible speed or promptness: to come to a friend's aid posthaste." I thought this was fitting when analyzing HTTP POST traffic. After all, when a user of a browser-based application clicks on a button or presses the enter key, shouldn’t they expect a quick reply? The HTTP POST is a method or operation that the server is to perform on the resource as identified by the Uniform Resource Identifier (URI). The POST method is a distant second behind GET in terms of popularity. Perhaps for that reason we don’t understand it as well when it comes to analyzing its behavior. Even the tool vendors (anything that collects a packet, even if it’s not a protocol analyzer per se) often blow off the importance of this vital HTTP operation, leaving us scratching our heads to figure out where the problem is with our web-based applications. Since this is one of the few blogs that actually compares some of the finer points when it comes to expert systems from various vendors, I’ll touch on how some of the analyzers handle HTTP POST analysis. But first let’s look at the basic HTTP POST operation. In a nutshell, a POST is telling the server to accept information and perform an operation in the context of the resource identified in the URI. A POST is typically used to submit the content of a form or to post a message. Another good example is submitting the content of web-based email when you click the send button. Note that for simple submissions were there are only a few variables, parameter(s) passed to the GET method will suffice. A search request is a good example of this. In your analysis, you may also come across the HTTP PUT. What’s the difference between POST and PUT? Simply put (ha), think of a POST as asking a server to perform some operation on the specifed data vs. a PUT that simply stores the data. (For more details on these and other methods, please refer to RFC 2616.) Meanwhile back to the problem at hand. Let’s start by looking at our first screenshot, from Wireshark, of a packet capture sending an email via Yahoo mail. Packet #4 is the POST header (similar to a GET, specifying the language, encoding, character set, and options such as cache-control and cookie) followed by the POST data (XML encoded SOAP in this case) in packet #5. Wireshark will show the reassembled PDU (i.e. both the header and data) in the last packet or packet #5. Other analyzers will show you the HTTP POST in the packet summary rather than "[TCP segment of a reassemble PDU]" that we see in Wireshark. As an example, the second screenshot shows the same trace in Sniffer.
Wireshark HTTP POST Packet Summary and Decode: The POST header in packet #4 is not displayed until later
Sniffer HTTP POST Packet Summary and Decode: The POST header summary is displayed in Packet #4, where it occurs
Personally, I like seeing where the POST begins. I also like seeing the reassembled packets. Of the four analyzers I use on a regular basis (Observer, OmniPeek, Sniffer, and Wireshark), only Sniffer and Wireshark show the reassembled packets in the decode window. Sniffer also shows the POST where it starts, in packet #4, along with the reassembly details of all packets associated with it. Thus, Sniffer wins this round. (Vendors hate it when I pick a superior feature from a competitor or point out a flaw. My hope is that they will take these points to heart to improve their product. The fact that no one analyzer has the best of everything is but one reason I use multiple tools. But I digress.) Now for a little response time analysis using multi-layer ACKs: The two TCP packets (#4 and #5) containing the POST data are acknowledged by the server’s TCP stack (not the application, an important distinction) in packets #6 and #7 respectively. The network + transport layer ACK time as measured from packet #4 to #6 is about 90 ms. The server’s application layer response time as measured from the POST continuation packet (which makes sense since the server cannot respond until the entire POST content (header + data) is received) to the HTTP OK status in packet #8 is 368 ms. We could subtract the 90ms network delay and figure that the server took about 278 ms to process the POST. Switching over to the OmniPeek analyzer, I noted that it correctly identifies the server + network response time of 368 ms. Sniffer is close, but it measures from the first POST packet rather than the complete POST transmission, giving a slightly higher value of 373 ms as the response time. Also, the OmniPeek expert was the only analyzer that flagged the HTTP POST response time as slow, if I lowered the threshold to 350 ms. As an exercise to the reader, try analyzing applications that use POST from both IE and Firefox. In the above web-based email case, I used IE 7 for this write-up, but I also checked it out with the latest version of Firefox. Interestingly, IE consistently sent the two POST packets back-to-back (#4 & #5 above) while Firefox would first wait for a TCP ACK to the POST header before sending the remainder. This underscores that you should not only check your applications for visual compatibility between differentbrowsers, but how they interact with servers at the protocol level. In this case, IE has a slight performance advantage. So there you have it. A little insight to help you from going POSTal next time you analyze HTTP.
Comments