Windows – When does a browser send HTTP payload separately from the HTTP request

httpiptcpwindows

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.

Best Answer

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.

Related Topic