Understanding “408 Request Timeout” on Apache with PHP

Question

Issue description - Apache logs

I found items similar to this one in the Apache log file:

166.147.68.243 [24/Feb/2013:06:06:25 -0500] 19 web-site.com "-" 408 - "-"

I’ve got custom log format and 408 here stands for status. The log format is:

LogFormat "%h %t %D %V \"%r\" %>s %b \"%{User-agent}i\"" detailed

And normally the line in the log file looks like

184.73.232.108 [26/Feb/2013:08:38:16 -0500] 30677 www.site.com "GET /api/search... HTTP/1.1" 200 205 "Zend_Http_Client"

This is why 408 error lines look strange to me. No request is logged and I have no idea on what should be optimized.

Questions

How to tackle the issue? What additional information or logs should I gather? What might cause the issue? Is this something wrong on the server? Or is this absolutely a network connectivity problem?

I’m addressing this because our customer complained that he has got 408 error on his mobile phone. I found many records in the log file but I have to admit I don’t know what to do with this.

---

My own research

There are several questions on this subject already here. But people are much more specific. Like they discus issues with some specific client software and scripts. Here I just got the error when opening some page on iPhone.

For example in HTTP, 408 Request timeout, it is suggested to do the GET request before POST. If I have custom client I can do this. But I can not control the behavior of the user’s browser.

Guess #1

When searching the Internet and thinking about the issue I found https://serverfault.com/questions/383290/too-many-408-error-codes-in-access-log

The suggestion is to update the Timeout config parameter back to its default value.

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

I tried the value 30 first because I thought 30 seconds should be enough. But even with 300 seconds default value, I continue to get the errors in the log. I did tail -f when I was writing this text and got more then 10 lines in a few minutes.

To me this does not look a complete solution.

Chatterer

I've just found the question serverfault.com/questions/383290/… – Chatterer

Our timeout was set to 5 instead of default 30. I've changed it back to default value 30. I'll put the update shortly if I'm still getting these errors in the log file. – Chatterer

So give an answer, by explaining why the other question on serverfault is the same, and accept that later. – Vierno

@Vierno What do you mean? – Chatterer

You have asked a question, and without an answer, your question will stay open. So it is a good habit to answer your (own) question, and accept it as the right answer later. See the etiquette for answering own questions. – Vierno

@Vierno Thank you for the clarification. I just have not thought about these things. – Chatterer

Answer 1

After some studies on the subject I came to the following answer. It is provided by our lead developer and I think it gives good explanation of the subject.

These errors are perfectly normal. They aren't a sign of a larger issue, but normal connections that are holding Apache open for longer than allowed.

For example, client's queries running them over and over kept Apache open. Apache responded by shutting him down appropriately.

If it hadn't, than a handful of people could take over our server and not allow anyone else to connect.

Most often these errors are coming from systems looking for exploits, and you can recreate it by opening a telnet session and leaving it open.

At the same time, tail -f the access log, and within X time (KeepAliveTimeout) you'll see your IP popup with the same error codes.

Back in the days of Apache 1.3, this error was common, but then 2.2 came out and they had it removed until enough of us asked for it to be returned since it give us ideas on how many people are holding open just the port, and not requesting an actual resource, etc.

I think nothing else should be done here except to make sure to set Timeout to some reasonable value as I have described in original question.

Chatterer

I don't think the KeepAliveTimeout is relevant here - that setting is used to control functionality that leaves connections open after a response has been sent. The key setting here (as you found) is Timeout (overall request / response timeout), but you may find that mod_reqtimeout is enabled and configured to timeout empty requests sooner (via RequestReadTimeout). – Antichrist

Actually the KeepAliveTimeout is relevant. If KeepAlive is On and the HTTP request is not completed in the KeepAliveTimeout time, it will cause a 408 error. If KeepAlive is Off, then the Timeout directive takes precedence. I've been testing this with slow embedded devices with Apache servers. – Rosenarosenbaum

Answer 2

Actually a lot of 408 messages in apache logs are a result pre-fetching mechanism in modern browsers. From looking in apache logs in the last 3 years the amount of 408 errors had more than doubled for the same traffic.

Nicaea

Could you link to information about how pre-fetching leads to 408 errors? – Vent

@Vent Although old, the following provides an explanation of Chrome's pre-fetching. How Chrome's pre-connect breaks HaProxy (and HTTP) – Aoristic

and a followup post from HAProxy: haproxy.com/blog/haproxy-and-http-errors-408-in-chrome – Catechize

Answer 3

If there is a Proxy set up in Apache, and the back end is not responding in a timely fashion for some reason, the same 408 - - will be seen in the logs. Proxy timeouts are configured separately, that's why changing the Apache default timeout doesn't seem to do anything about those requests.

Cicisbeo

Answer 4

All http requests support username and pw. No username="-", no password="-", password="*".

Nl

describde more this answer. – Presbytery

This answer has no obvious connection to the question. – Sanctity