Persistent HTTP 429 Rate Limiting on *.githubusercontent.com Triggered by Accept-Language: zh-CN Header #157887
Replies: 55 comments 22 replies
-
|
logined too 登录了也一样 |
Beta Was this translation helpful? Give feedback.
-
|
not
|
Beta Was this translation helpful? Give feedback.
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
same issue |
Beta Was this translation helpful? Give feedback.
-
|
Same problem. |
Beta Was this translation helpful? Give feedback.
-
|
I also encountered the same problem. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
I turn to jsDelivr instead |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
same problem, i cannot solve it |
Beta Was this translation helpful? Give feedback.
-
|
same problem |
Beta Was this translation helpful? Give feedback.
-
|
Not only triggered by I'm getting the error in GitHub Actions! Why in the world is GitHub rate limiting their own services? |
Beta Was this translation helpful? Give feedback.
-
|
same |
Beta Was this translation helpful? Give feedback.
-
|
Same problem. My avatar cannot be displayed. |
Beta Was this translation helpful? Give feedback.
-
|
It's back to normal now. |
Beta Was this translation helpful? Give feedback.
-
|
broke again. |
Beta Was this translation helpful? Give feedback.
-
|
same |
Beta Was this translation helpful? Give feedback.
-
|
Just saw a solution in another discussion, and it worked for me: https://github.com/orgs/community/discussions/157851#discussioncomment-12987612 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
The same issue for builds |
Beta Was this translation helpful? Give feedback.
-
|
I am experience the same issue in CI in recent days. Building docker containers that fetch some public GH files have started to randomly and frequently fail. |
Beta Was this translation helpful? Give feedback.
-
|
I have set the env.GH_TOKEN - name: Build with Node
run: |
node conf/generate.blackmatrix7.mjs
node conf/generate.blocklist.mjs
node conf/generate.esbuild.mjs
node conf/generate.filter.mjs
env:
GH_TOKEN: ${{ github.token }}Use env.GH_TOKEN by process.env.GH_TOKEN const res = await fetch(src, {
method: 'GET',
cache: 'no-cache',
credentials: 'omit',
headers: {
Authorization: `Bearer ${process.env.GH_TOKEN}`,
'Content-Type': 'text/plain'
}
});I dose not work |
Beta Was this translation helpful? Give feedback.
-
|
429 should not happen in GitHub Actions Env |
Beta Was this translation helpful? Give feedback.
-
|
Same issue with credentials: 'include', |
Beta Was this translation helpful? Give feedback.
-
|
Not sure why github thought making the limit as low as they did was a good idea, this breaks thousands if not tens of thousands of repos that have automatic install scripts for users; that run commands and download from github. I keep encountering this myself every couple minutes and its making it almost impossible to test or debug stuff without changing ips constantly. |
Beta Was this translation helpful? Give feedback.
-
|
I am suddenly getting 429s from a GitHub Action that is actually using an auth token. It broke our deployment workflow. |
Beta Was this translation helpful? Give feedback.
-
Same here—seeing 429s on a GitHub API access that’s using an auth token. Broke our deployment flow as well. Not sure if this warrants a new thread or if others are seeing the same thing. |
Beta Was this translation helpful? Give feedback.
-
|
This breaks CI features for us. If it continues I will have to disable certain CI checks/tests, possibly move some things off GitHub. |
Beta Was this translation helpful? Give feedback.
-
We were seeing the same thing. You can switch to using the REST API. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for pointing this out, it is possible for patches (i.e. |
Beta Was this translation helpful? Give feedback.
-
|
So, instead of 429 we are now receiving 403 errors, authenticated. |
Beta Was this translation helpful? Give feedback.
-
|
This doesn't seem related to |
Beta Was this translation helpful? Give feedback.
-
|
Does anyone know how to actually authenticate to raw.githubusercontent.com? I posted a discussion at https://github.com/orgs/community/discussions/160828 about this. |
Beta Was this translation helpful? Give feedback.
-
|
Sad! This happens here too 😩 |
Beta Was this translation helpful? Give feedback.
-
|
happening too to obsidianmd plugins and themes workflow... |
Beta Was this translation helpful? Give feedback.
-
|
We've been encountering this all day for Aliucord, with users getting 404s and 429s at random. Not sure what's been going on. |
Beta Was this translation helpful? Give feedback.
-
|
Getting this today, too. Viewing Raw Gists is not working, 429. |
Beta Was this translation helpful? Give feedback.
-
|
Happening now too. Totally broke ROS package dependencies installation through the When this happened in April you could still get them to build after retrying, now it just fails everytime. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
For the people like me arriving here due to the issues in the last few days, check https://github.com/orgs/community/discussions/177971 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
General
Body
Hi GitHub Community and Staff,
I've recently encountered a persistent issue where accessing static assets hosted on githubusercontent.com subdomains results in an HTTP 429 "Too Many Requests" error. The error page displays the following message:
Affected Domains
Through testing, this issue seems specific to certain subdomains under
githubusercontent.com, including:Interestingly, requests to avatars.githubusercontent.com appear to be working normally without triggering this rate limit.
Key Finding:
Accept-LanguageHeaderBased on my own testing and reports from other users in the community, this rate limiting appears to be directly correlated with the Accept-Language header in the HTTP request. Specifically, if the request includes
zh-CN, the 429 error is triggered. When I modify the request header to use a different language code (e.g., en-US, en), the same resources load successfully without any rate limiting.Concerns
Persistence: Despite the error message suggesting waiting, this rate limit does not seem to resolve itself over time (even after hours or days) as long as the Accept-Language: zh-CN header is present. This indicates it might not be a standard, temporary rate limit based on request volume from an IP, but rather a more targeted restriction.
Rationality of Language-Based Limiting: Implementing access restrictions based on the browser's preferred language setting seems unusual and potentially problematic. A user's language preference doesn't necessarily correlate with malicious activity or excessive resource consumption. This restriction negatively impacts legitimate users whose systems or browsers are configured to use Chinese.
Suggestion
If rate limiting is indeed necessary for certain traffic patterns or regions, wouldn't using GeoIP data be a more appropriate and effective method? Targeting restrictions based on the source IP address's geographical location seems more logical for managing regional load or mitigating region-specific abuse, rather than relying on a user's language setting.
Could the GitHub team please investigate this behavior?
Accept-Languagebased rate limiting intentional?Thank you for your time and consideration.
Beta Was this translation helpful? Give feedback.
All reactions