Bug #2401
closed
rudder-server Installation : chrome://net-internals/#httpThrottling
Added by Francois BAYART over 12 years ago.
Updated over 11 years ago.
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
- 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...
- Priority changed from N/A to 2
- Target version changed from 2.3.7 to 2.3.8
- 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."
- Target version changed from 2.3.8 to 2.3.9
- 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?
- Assignee deleted (
Matthieu CERDA)
- Target version changed from 2.3.9 to 2.3.10
- Status changed from Discussion to In progress
- Status changed from In progress to Discussion
- Assignee set to Matthieu CERDA
- Target version changed from 2.3.10 to 2.3.11
- Status changed from Discussion to 8
Matthieu, could you investigate on this ticket please ?
- 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.
- % Done changed from 0 to 50
- 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 ?
- Target version changed from 2.3.11 to 2.3.12
- Status changed from Discussion to In progress
- Assignee changed from Jonathan CLARKE to Matthieu CERDA
- 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
- Status changed from Pending technical review to Pending release
- Status changed from Pending release to Released
Also available in: Atom
PDF