mirrors/haproxy
1
0
Fork 0
mirror of https://git.haproxy.org/git/haproxy.git/ synced 2025-09-23 06:41:32 +02:00
Code Issues Projects Releases Wiki Activity

DOC: document the workarouds for Google Chrome's bogus pre-connect

Browse Source 
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.
This commit is contained in:
Willy Tarreau 2014-05-23 17:38:34 +02:00
parent 9f66aa9cc4
commit 2705a61d8c
1 changed files with 23 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc/configuration.txt
View File

@ -2487,6 +2487,7 @@ errorfile <code> <file>
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 @@ timeout http-request <timeout>
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 @@ timeout http-request <timeout>
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 @@ easier finding and understanding.
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