Skip to content

July 12, 2009

9

Malformed HTTP Protocol from Yahoo Traffic Server (YTS)?

by Joe Kuan

NetworkingI 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.

http response

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.

yts malformed 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.

http request yts

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.



I work for iTrinegy and here are my other technical blogs

Advertisements
9 Comments Post a comment
  1. Jul 26 2009

    Are you still seeing this problem with these requests? If so, can you send me a URL (or two) which experiences the problem?

    Thanks!

    Reply
    • Joe Kuan
      Jul 26 2009

      Hiya,

      I have updated the post with the URIs. The data in the blog is from a capture file about a year ago. However, I still see this problem in another customer site couple weeks ago although not as frequent.

      Thanks
      Joe

      Reply
  2. johnny
    Aug 7 2009

    Hello. Thank you for this great info! Keep up the good job!

    Reply
  3. Aug 7 2009

    Cool, thanks for the links. Just as an update, this is not a problem with Traffic Server (which I work on), but the property who owns the content.

    Thanks for pointing this out, we’ll track down the responsible parties, and hopefully we can get this resolved.

    Thanks!

    — Leif

    Reply
  4. Aug 8 2009

    Didn’t understood the last part :s could you explain better please?

    Reply
    • Joe Kuan
      Aug 9 2009

      Please can you quote which part that you don’t understand?

      Reply
  5. Nov 3 2009

    molamola is probably referring to “but the property who owns the content.”

    That simply means that the missing CR is coming from bytes injected by a process outside of Traffic Server itself, and that the process is owned by a content division of yahoo or an external partner.

    Reply
  6. Nov 3 2009

    In case you missed it, we finally pushed the code to Apache SVN last week. More details are available at

    http://cwiki.apache.org/confluence/display/TS/Traffic+Server

    Reply
  7. pand0ra
    Nov 1 2011

    The GET request is malformed.

    GET http://l.yimg.com/eur.yimg.com/ng/mo/5/20081202/16/2370884746.png HTTP/1.1

    is not a valid GET request. the request should not have the domain info (http://l.yimg.com) and should be stripped off for a valid request.

    Correct GET request:
    GET /eur.yimg.com/ng/mo/5/20081202/16/2370884746.png HTTP/1.1

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: