DOC: document the workarouds for Google Chrome's bogus pre-connect
More and more people are complaining about the bugs experienced by
Chrome users due to the pre-connect feature and the fact that Chrome
does not monitor its connections and happily displays the error page
instead of re-opening a new connection. Since we can work around this
bug, let's document how to do it.
diff --git a/doc/configuration.txt b/doc/configuration.txt
index bfb5fc3..e2fe0df 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2487,6 +2487,7 @@
Example :
errorfile 400 /etc/haproxy/errorfiles/400badreq.http
+ errorfile 408 /dev/null # workaround Chrome pre-connect bug
errorfile 403 /etc/haproxy/errorfiles/403forbid.http
errorfile 503 /etc/haproxy/errorfiles/503sorry.http
@@ -7688,7 +7689,13 @@
this abuse because it is an inactivity timeout, which means that if the
attacker sends one character every now and then, the timeout will not
trigger. With the HTTP request timeout, no matter what speed the client
- types, the request will be aborted if it does not complete in time.
+ types, the request will be aborted if it does not complete in time. When the
+ timeout expires, an HTTP 408 response is sent to the client to inform it
+ about the problem, and the connection is closed. The logs will report
+ termination codes "cR". Some recent browsers are having problems with this
+ standard, well-documented behaviour, so it might be needed to hide the 408
+ code using "errorfile 408 /dev/null". See more details in the explanations of
+ the "cR" termination code in section 8.5.
Note that this timeout only applies to the header part of the request, and
not to any data. As soon as the empty line is received, this timeout is not
@@ -7706,7 +7713,7 @@
effect, unless the frontend is in TCP mode, in which case the HTTP backend's
timeout will be used.
- See also : "timeout http-keep-alive", "timeout client".
+ See also : "errorfile", "timeout http-keep-alive", "timeout client".
timeout queue <timeout>
@@ -12529,7 +12536,20 @@
client side for PPPoE networks which cannot transport full-sized
packets, or by clients sending requests by hand and not typing fast
enough, or forgetting to enter the empty line at the end of the
- request. The HTTP status code is likely a 408 here.
+ request. The HTTP status code is likely a 408 here. Note: recently,
+ some browsers such as Google Chrome started to break the deployed Web
+ infrastructure by aggressively implementing a new "pre-connect"
+ feature, consisting in sending connections to sites recently visited
+ without sending any request on them until the user starts to browse
+ the site. This mechanism causes massive disruption among resource-
+ limited servers, and causes a lot of 408 errors in HAProxy logs.
+ Worse, some people report that sometimes the browser displays the 408
+ error when the user expects to see the actual content (Mozilla fixed
+ this bug in 2004, while Chrome users continue to report it in 2014),
+ so in this case, using "errorfile 408 /dev/null" can be used as a
+ workaround. More information on the subject is available here :
+ https://bugzilla.mozilla.org/show_bug.cgi?id=248827
+ https://code.google.com/p/chromium/issues/detail?id=85229
CT The client aborted while its session was tarpitted. It is important to
check if this happens on valid requests, in order to be sure that no