如何浪费带宽、电池电量并惹恼系统管理员

好吧，我们先来谈谈 feed 阅读器之外的东西。彻底失效的网络浏览器怎么样？没错，就是那些。

这个。这是个东西。数一数破损的：

知识产权– [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:26 -0700] “GET /w/css/main.css HTTP/1.1” 200 1651 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/feed.png HTTP/1.1” 200 689 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed/ HTTP/1.1” 200 8052 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “GET /w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20 ip – – [28/Jun/2024:14:44:27 -0700] “获取/w/2024/05/27/feed//favicon.ico HTTP/1.1” 404 20

首先，你为什么需要请求同一个链接 12 次？不，划掉，15 次，因为在获取 css 和 feed 图标后，它还会请求 3 次。

然后它转到 favicon，哪个傻瓜认为请求“/favicon.ico”的正确方法是将基本路径添加到它前面？微软在 90 年代强加给我们的这个该死的东西应该位于顶层。它不是单个目录的一部分。那太愚蠢了。

然而，这个东西在尝试获取它时却决定打败网络服务器。

我曾经想知道到底是什么会这么愚蠢。这些不良请求上的用户代理并不是特别有用。但是，有一天，我很幸运地注意到该集合中的第一个请求中有一个非常有趣的小细节（而其他请求则没有）：

FxiOS/127.1

FxiOS。即 iOS 版 Firefox。这本身就足以让我开始寻找，哦，看看我发现了什么。

访问网站时请求发送垃圾邮件