I am trying to understand why the web server behaves differently for the following bad requests:

Method                                                     Proto Status Req Body Res Referrer        User Agent                                                                             HTTPS Encrytion
GET /                                                      HTTP/1.0 400  11 362    0 -               -                                                                                      - -
\x80w\x01\x03\x01                                                   400  29 226    0 -               -
GET /api/                                                  HTTP/1.0 400  32 226  392 -               -
GET /                                                      HTTP/1.1 400 316 226 4295 -               -
GET /                                                      HTTP/1.0 400 735 226 4121 -               -                                                                                      TLSv1.2 RC4-SHA
GET http://example.com/?PHPSESSID=1abcdef0123456ABCD_EFGHI HTTP/1.1 400 167 226  392 -               -
GET /HNAP1/                                                HTTP/1.1 400 369 226  392 Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.0.1234)
GET http://example.net/headers                             HTTP/1.1 400 423 226  392 -               Mozilla/5.0 (X11; Ubuntu; Linux i686 on x86_64; rv:20.0) Gecko/20100101 Firefox/20.0

I do not understand why the server is returning 0 byte for first and second request and why it is returning more than 4kB in the the 4th and 5th request when the normal size is exactly 392 bytes.

Note that I do not have any custom error page for HTTP error code 400.

2 Answers 2


Request headers can cause the size of responses to vary. For example if the requesting device or browser allows for Gzip encoding they will let your webserver know that they want the content in gzip format which is a lot smaller. Also pages which are dynamically generated can vary in size. In your example you have /api/. Unless if your api is pumping out a static page (not likely) then you are going to get different size headers.

Pretty much anything that modifies the response (the page, or the encoding of the page) or anything which modifies the request (user agent, accept headers) will change the sizes of these headers. Your best bet is not to worry about it, as it is the norm.

Where you should pay attention is the request sizes for static items such as JS, CSS and images. That is where you do your performance tweaking to begin with, and then move down the chain to different bottlenecks (usually in code).

  • I believe, except for the first request where the body size is larger, the rest are return in compressed format. Contrary to your second point, all of the responses are static as these are the same error 400 page, which is the reason why I am asking. It is not about troubleshooting performance bottlenecks but understanding the behaviour of the web server. Aug 14, 2014 at 3:12

These are all 400 (Bad Request) responses. It seems likely that your web server would include some information about what with the request is bad. That could account for much of the size variance.

In the case of the zero response size, it seems likely that the connection was closed before the response was sent.

  • I do not have a custom error page for 400 error, so I expect the response size would be of a constant size 392 bytes. In case of 0 size, yes, I agree with you that premature closure of connection could be the cause. But how do I account for the 4kB output in case 4 and 5? Aug 28, 2014 at 2:53
  • Why would you expect it to be a constant size? The server might ouput something like "Unexpected header: Foo: xeousthesesthoauestahoeue......" which is quite long. I would expect most servers to have rather dynamic default 400 errors. Aug 28, 2014 at 3:09
  • If you look at the example above, the response size for 400 error is typically 392 bytes. Why would the web server output custom headers like Foo: xeous...? I thought the http response format is quite standard. Aug 28, 2014 at 8:15
  • There are many reasons that requests can be bad. I would expect servers to be informative about why any particular request was malformed. Aug 28, 2014 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.