我认为人们并没有真正意识到他们的某些软件会造成什么样的混乱。那天晚上，我收到了一些反馈，有人对网站无法访问感到困惑。根据运行的跟踪路由，此人认为可能是运营商 A 或运营商 B，甚至可能是我自己的托管主机。
我本来会直接回复这个人，但他们没有留下任何联系信息，所以我所能做的就是写一篇文章，希望它能传达给他们和其他有同样情况的人。
它不是任何一家运营商，也不是飓风电力。这是我的结局，这并非偶然。自动过滤的主机通常运行某种违背最佳实践的提要阅读器，然后惹恼 Web 服务器，接收 429，然后忽略这些并继续运行。
Web 服务器做自己的事情。我什至不在循环中。我可以睡着了，或者完全离线，它会在没有我的情况下正常运行。
典型的时间表是这样的：
- 00:04:51 GET /w/atom.xml，无条件。
满足 200, 502 KB。 - 00:24:51 GET /w/atom.xml，无条件。
拒绝429 。
建议（通过 Retry-After 标头）一天后回来，因为他们不愿意或无法执行有条件的请求。 - 00:44:51 GET /w/atom.xml，无条件。
相同的 429 + 之后重试。 - 01:04:51 GET /w/atom.xml，无条件。
就像上次一样。 - 01:24:51 GET /w/atom.xml，无条件。
同样的事情，又来了。
在这附近的某个地方，网络服务器认为它没有被监听，因此它也决定停止监听。
一段时间后，它会“原谅”，然后事情会再次正常进行，但当然，如果仍然有一个坏的提要阅读器在那里运行，它最终会重新开始这个过程。
无条件请求的 20 分钟重试率是一种浪费。即每小时 3 个请求，即每天 72 个请求。这将是大约 36 MB 的流量，这是完全无用的，因为它会一遍又一遍地提供相同的提要内容。
将其乘以一群人，因为它是一种流行的提要，这应该可以解释为什么我已经对这个风车倾斜了一段时间了。
如果您正在运行提要阅读器并想知道其行为是什么样的，我今年早些时候设置的“提要阅读器分数”项目仍在运行，并且只是嗡嗡作响，一如既往地记录数据。
您只需将您的读者指向一个特殊的个性化 URL，您将收到一个营养成分为零的提要，但您的读者的许多行为 (*) 将被分析并在报告页面中提供。
这很容易……而且我什至不收费。 （也许我应该？）
…
(*) 我说_许多_行为，因为一堆这些事情已经证明我的方法只是在同一主机上为人们提供一堆唯一键路径是不够的。其中一些 feed 阅读器只是去创建自己的路径，这是垃圾，但这也意味着我在 /one/pspecial/path 的愚蠢的小 CGI 程序看不到它。这也意味着当他们钻取 / 或 /favicon.ico 或其他内容时，它看不到它。我不可能预测他们所有的小丑行为，需要一把更大的锤子。
显然这里还有第二个系统等待编写。
像往常一样，在你开始做这件事之后，需求就会被了解。