Malformed HTTP Protocol from Yahoo Traffic Server (YTS)?
I noticed that my HTTP protocol analyser module of AppQoS reported some malformed HTTP packets. This was strange at first sight as the RFC for HTTP protocol is pretty well defined or this may be a bug in my module. So I inspected the captured packet with Wireshark/Ethereal. Thankfully, it wasn’t a bug in my module, it was actually the packet. In fact, the packet was a HTTP reply generated from a YTS server – Yahoo Traffic Server. By specifying: http.server == “YTS/1.17.8”, I got a list of response packets from YTS webserver.
These are all the response from requesting image files and the malformed packets are the ones just showing “HTTP/1.1 200 OK” without the image format name, eg frame number 7717, 7723 etc.
Here is the details of a malformed HTTP reply packet.
As you can see, the CR characters after some of the message headers (Content-Length, Content-Type, Last-Modified, Cache-Control and the trailer CR) were missing. However, the HTTP request for the response message does look fine to me. The following shows the content of a request packet.
From the list of traffics going forth and back to the YTS, the malformed HTTP packets seem only occurred when the GET method was requesting for an PNG image and the reply came back with Content-Type: image/gif whereas the content in the reply message body was still PNG image. Strangely, there were other GET methods for PNG and GIF images and the responses are all fine. Another special condition added in the HTTP protocol analyser.
Here are some of URIs that caused the malformed responses.