过去，我曾写过一些关于行为不端的提要员的投诉。一年多一点了，情况还是差不多。仍然有一些人认为每分钟或每 2 分钟或其他任何方式进行轮询很酷。这不酷。这毫无用处。我不经常更新这个东西，那么浪费这些资源有什么意义呢？
出现了一些亮点。至少有一个人打开了 If-Modified-Since 标头，甚至在他们的 User-Agent 标头中添加了一些评论让我知道。那是超越，所以感谢你是谁。
但是，那里仍然有很多行为不端的提要读者，所以是时候谈谈胡萝卜和大棒了。
胡萝卜基本上是：如果你有一个行为良好的提要阅读器，你将继续能够在合理的时间内发现我的提要上的新帖子。这是大多数人。大多数人都做对了。谢谢你。
坚持是：如果你不这样做，你就不会。需要更长的时间才能注意到这里有什么不同。
什么是行为良好的提要阅读器？我主要关心的是不必为没有理由再次拉取它的人提供完整的提要。这意味着发出条件请求——你的客户端告诉我的服务器它看到的东西的最新版本，我的服务器会“好的，没有什么不同”或（偶尔，在更新后）“哦，酷，这是最新的”。
你怎么做到这一点？理想情况下，您只需运行提要阅读器，它就会解决问题。但是，请相信我，从过去一周查看太多此类内容的功能请求和代码库来看，这似乎并不常见。
这就是它的技术部分的工作原理，以免有人声称它太难实施。当您获取 Feed 时，我的服务器会发送一些标头。其中两个可能适用于此。现在，它们看起来像（但不完全像）这样：
最后修改时间：2023 年 1 月 6 日星期五 00:00:00 GMT ETag：“xxxxx-yyyyyyyyyyyy”
行为良好的 HTTP 客户端可以在执行提取时存储这些值，然后在后续请求中返回其中一个或两个。第一个变成If-Modified-Since，另一个变成If-None-Match。请注意，第二个实际上需要围绕它的“”，否则它将不起作用。 （是的，我知道。不是我做的。）
If-Modified-Since：格林威治标准时间 2023 年 1 月 6 日星期五 00:00:00
…和/或…
如果不匹配：“xxxxx-yyyyyyyyyyyy”
现在，您的 HTTP 客户端软件应该将其作为某种定义明确的设置的某种参数，您可能不应该直接设置标头，但我们仍在为一个已有 30 多年历史的协议拼凑石头。但我离题了。
（旁注：这意味着您的提要阅读器必须为每个提要维护一些状态。您不能只是无状态地获取 URL 直到时间结束。那是非常愚蠢的。）
拿之前拿到的东西，如上图一样交还。如果什么都没有改变，你会得到一个 304 HTTP 代码，这意味着“没什么新的”。这是一个简短的交易，并且使用的资源很少。
如果提要已更新，比如说，因为我写了一篇新帖子，或者对现有帖子进行了更新或拼写错误修复或其他任何操作，那么您会自动将其返回为 200，以及一组新的标题。您的提要阅读器有责任记住这些字段中的一个或两个，然后在以后使用它们。
在我看来，带有适当“IMS”或“INM”标头的请求被视为条件请求。我比较善意地看待那些。这些往往来自想要做正确事情的人。
既没有“IMS”也没有“INM”标头的请求是无条件的，我不喜欢那些。我知道每个人都会时不时地去买一些“新鲜”的东西。这是一个给定的。你必须以某种方式启动泵。我不在乎那个。
但是当有人要求完整的提要并且不尝试保存时，他们一遍又一遍地这样做，比如每 2 秒一次？那是我坐下来开始编码的时候。我做的代码。这就是我写这篇文章的原因。行为不端的提要阅读器将不再及时更新。
我应该注意到，一个特定的提要阅读器发送了“Wed, 01 Jan 1800 00:00:00 GMT”，这完全是胡说八道。你编造的，你知道的。从来没有人为您提供过具有该价值的页面。看，这实际上是已知的病态行为。发送不算是有条件的。
坏客户得到 429。这意味着放慢你的速度。
给书呆子的额外说明：是的，仍然有可能滥用完美形成的条件请求。请不要试图找出那个点在哪里。请记住，我不经常发帖。您不需要经常进行轮询。