Bug #2401
closedrudder-server Installation : chrome://net-internals/#httpThrottling
Description
I have installed "rudder-server" on Debian Squeeze with rudder repository.
When I have opened the web page the "waiting screen" was run but after some seconds this beautiful appear on my Chrome browser :
-----snip here-----
Access to the webpage was denied
It is likely that the server hosting the webpage has been overloaded or encountered an error. In order to avoid causing too much traffic and making the situation worse, Google Chrome has temporarily stopped allowing requests to the server.
If you think this behavior is undesirable, for example, you are debugging your own website, please visit the chrome://net-internals/#httpThrottling page, where you can find more information or disable the feature.
Error 139 (net::ERR_TEMPORARILY_THROTTLED): Requests to the server have been temporarily throttled.
-----snip here-----
Files
Updated by Jonathan CLARKE over 12 years ago
- Category set to Web - UI & UX
- Target version set to 2.3.7
- Estimated time deleted (
0.00 h)
The reason for this is the way the "loading" page is implemented: it is a special page served by Apache in case a 503 error would be returned. The page served then causes a reload to happen every 4 seconds, to see if the application is ready and the 503 has gone away.
But Chrome seems to be "clever" and catch this. We should change something here...
Updated by Nicolas PERRON over 12 years ago
- Target version changed from 2.3.7 to 2.3.8
Updated by Nicolas PERRON over 12 years ago
- Status changed from New to Discussion
Maybe we should reduce time before reloading the page ? Or should we redirect to a remote URL instead of a local file ?
"Note that when you specify an ErrorDocument that points to a remote URL (ie. anything with a method such as http in front of it), Apache will send a redirect to the client to tell it where to find the document, even if the document ends up being on the same server. This has several implications, the most important being that the client will not receive the original error status code, but instead will receive a redirect status code. This in turn can confuse web robots and other clients which try to determine if a URL is valid using the status code. In addition, if you use a remote URL in an ErrorDocument 401, the client will not know to prompt the user for a password since it will not receive the 401 status code. Therefore, if you use an ErrorDocument 401 directive then it must refer to a local document."
Updated by Jonathan CLARKE about 12 years ago
- Target version changed from 2.3.8 to 2.3.9
Updated by Jonathan CLARKE almost 12 years ago
- Assignee set to Matthieu CERDA
Matthieu, we think this can be worked around with an Apache config to send a 200 return code instead of 503. can you investigate?
Updated by Jonathan CLARKE almost 12 years ago
- Assignee deleted (
Matthieu CERDA)
Updated by Nicolas PERRON over 11 years ago
- Target version changed from 2.3.9 to 2.3.10
Updated by Nicolas PERRON over 11 years ago
- Status changed from Discussion to In progress
Updated by François ARMAND over 11 years ago
- Status changed from In progress to Discussion
Updated by Matthieu CERDA over 11 years ago
- Target version changed from 2.3.10 to 2.3.11
Updated by Nicolas CHARLES over 11 years ago
- Status changed from Discussion to 8
Matthieu, could you investigate on this ticket please ?
Updated by Matthieu CERDA over 11 years ago
- Status changed from 8 to In progress
According to this doc (Chromium): http://www.chromium.org/throttling
We should add a "X-Chrome-Exponential-Throttling: disable" header in the Apache response to prevent this.
Updated by Matthieu CERDA over 11 years ago
- % Done changed from 0 to 50
Note, on old Chrome version, disabling this behavior server-side is not possible: http://www.chromium.org/throttling/anti-ddos-http-throttling-in-older-versions-of-chrome
And masking the 502 error code from Jetty with a 200 with Apache does not seem to be something normal (very little doc about this).
Updated by Matthieu CERDA over 11 years ago
- Status changed from In progress to Discussion
- Assignee changed from Matthieu CERDA to Jonathan CLARKE
We can solve this by adding the following entry, requiring mod_headers:
<LocationMatch "/rudder"> Header add X-Chrome-Exponential-Throttling "disable" </LocationMatch>
Is this an acceptable solution ?
Updated by Matthieu CERDA over 11 years ago
- Target version changed from 2.3.11 to 2.3.12
Updated by Matthieu CERDA over 11 years ago
- Status changed from Discussion to In progress
- Assignee changed from Jonathan CLARKE to Matthieu CERDA
Updated by Matthieu CERDA over 11 years ago
- Status changed from In progress to Pending technical review
- % Done changed from 50 to 100
- Pull Request set to https://github.com/Normation/rudder/pull/191
PR available.
Be careful and commit http://www.rudder-project.org/redmine/issues/3534 first !!!
Updated by Matthieu CERDA over 11 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset 4c876f0add36579150a28c0c36b417ab531c4f4b.
Updated by Matthieu CERDA over 11 years ago
Applied in changeset 3a5a3e199c2e10faad3cf6ef42be698fca38838e.
Updated by Jonathan CLARKE over 11 years ago
Applied in changeset 0f0abc2e02d206ade91ec9076c083775bc95f6f7.
Updated by Nicolas PERRON over 11 years ago
- Status changed from Pending release to Released