What is the URL of the page with the issue?
pkg.go.dev
What is your user agent?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Safari/605.1.15
Screenshot
What did you do?
- Use public Wi-Fi connection (possibly with other golang devs?)
- Search pkg.go.dev
- Go to a package page
- Repeat a few times
What did you see happen?
429 Too Many Requests
Full response via xh:
HTTP/2.0 429 Too Many Requests
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
content-length: 142
content-type: text/html; charset=UTF-8
date: Mon, 18 Aug 2025 11:38:54 GMT
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>429</title>429 Too Many Requests
What did you expect to see?
Error should not occur when using the site normally (browser/no automation).
Responses should include an indication of request budget at least in HTTP headers for scripting users/diagnosing.
Block time should be lower in less severe cases: I'm still waiting after 15 minutes. Or perhaps me checking every couple of minutes or so is prolonging the block? That isn't ideal, either.
Homepage route could be cached, marked cacheable and exempted from rate.
Comment From: seankhliao
how much is a few times, and any browser settings / extensions we should know about?
Comment From: alanpearce
It seems to vary, which is why I wasn't more specific. Sometimes it's around 3, sometimes it doesn't show up for quite a while.
Not to my knowledge, otherwise I would have mentioned.
Comment From: cagedmantis
cc @golang/pkgsite
Comment From: alanpearce
I think the public wifi was not the cause, actually. I've noticed that it's actually Dash triggering the rate limit when fetching/updating package documentation. I also assumed that browsing with a typical browser would be subject to different limits, but I guess only rudimentary IP blocking is in place at the moment.
I've sent a message to the developers of Dash so that they can improve their request scheduling or use go doc --http, but I still think that there are improvements that could be made on the server side.
Comment From: jba
there are improvements that could be made on the server side
What did you have in mind?
Comment From: alanpearce
I mentioned most ideas in the issue already, but here they are again:
Responses should include an indication of request budget at least in HTTP headers for scripting users/diagnosing.
Block time should be lower in less severe cases: I'm still waiting after 15 minutes. Or perhaps me checking every couple of minutes or so is prolonging the block? That isn't ideal, either.
Homepage route could be cached (server-side), marked cacheable (browser) and exempted from rate-limiting
Also just thought it might be reasonable that cookie'd users get a different limit