2

Under what circumstances would you expect a web browser split an HTTP request into two IP packets, even if the sum of the packet sizes is still less than the maximum segment size? I would assume that this would always be sent as a single packet, but my experience is showing otherwise.

Using Microsoft Network Monitor to analyze HTTP traffic, I occasionally see a request that is divided into two IP packets, as shown below

HTTP:Request, POST /foobar.htm (PacketID=55178, TotalLength=528)
  POST /foobar.htm HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  ...etc...

HTTP:HTTP Payload, URL: /foo.htm (PacketID=55179, TotalLength=98)
  param1=foo&param2=bar&param3=foo+bar

I've only seen this happening on Windows XP clients so far, but it doesn't happen on all XP clients. And on the affected systems, both IE8 and Firefox exhibit the same double-packet behaviour.


Some context: We recently started using a third-party software package that provides a web application on our intranet. But instead of using a real web server like IIS or Apache, the software implements its own HTTP server internally.

Because the server uses a naive implementation of HTTP, it only inspects the first packet of an HTTP request, and misses the arguments sent in the second packet. This causes the request to fail.

1
  • Just for curiosity - what product is implemented in such a stupid (and non-TCP-compliant) way?
    – Robert
    Dec 6, 2011 at 12:54

2 Answers 2

3

It's random and unpredictable, and if you care, you are doing something horribly wrong.

Because the server uses a naive implementation of HTTP, it only inspects the first packet of an HTTP request, and misses the arguments sent in the second packet. This causes the request to fail.

I can't figure out what you're trying to say there. If it's actually looking at packets, it's an implementation of TCP, not HTTP (since the packets are packets according to the TCP specification). A sensible HTTP implementation would never be looking at packets at all.

If you really mean the HTTP server looks at the packets, then it has to reconstruct the TCP data stream and then follow the HTTP protocol. The end of an HTTP request is marked with two <CRLF>s in the TCP byte stream. Any other method of detecting the end of an HTTP request is broken.

Since the first packet does not contain an HTTP end-of-request sequence, it clearly cannot contain the entire request.

An HTTP server must follow the HTTP specification, or it's not an HTTP server. The HTTP specification only specifies what bytes go in the TCP data stream. It says nothing about segmentation, which is good because in practice applications would have no way to control that. It specifies how the end of a request is identified, and code that doesn't comply with that specification is not an HTTP server. It implements an HTTP-like protocol that may or may not be compatible with HTTP.

2
  • Although I agree with all of your comments, it does not answer my question. The software sucks and we are getting rid of it. But I'm still curious about the circumstances.
    – Nic
    Dec 6, 2011 at 1:03
  • It's random and unpredictable. Because nothing is supposed to care, no special effort is made to make it one way or the other way. (It can depend on how the client is coded, whether the client gets to keep the CPU while it's processing the entire request, whether a proxy is used, the MTU of the smallest link on the path, whether active bandwidth management devices are being used, and who knows what else.) It's not that the software "sucks", it's simply not an HTTP server, and so it cannot be accessed with an HTTP client. Dec 6, 2011 at 1:19
1

How are the POSTs in question being made - are the ones that are spilt made via XMLHTTPRequest i.e. AJAX?

AJAX POSTs send the headers and body as at least two separate TCP packets.

There's a blog post about it on the Yahoo developer network from a few years back.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .