Google chrome HTTP头检测Google Chrome的预加载请求

Google Chrome 17推出了一款新的浏览器，它可以在实际发出请求时预加载网页以提高渲染速度（点击omnibar中的enter键）

两个问题： 服务器端是否有HTTP头来检测这样的请求，如果确实存在HTTP头，为了防止这种预加载（防止可能产生不必要影响的意外请求），正确的响应是什么

Google Chrome在发出预加载请求之前是否检查robots.txt？ 是否有一个robots.txt设置只针对这种特定行为？（我支持/希望不允许已经生效）

是否有一个元标签通知谷歌Chrome不再在当前域上预加载

当Firefox预取内容时（应推荐人页面的要求） 标记），它随请求发送以下标头：X-moz： 预取

Safari也使用：X-Purpose:preview进行类似操作。据此, 票，Chrome也有

对于预渲染，Chrome不会向 客户相反，必须使用JS中的页面可见性API

---

，

Chrome在2011年停止发送X-Purpose标头，他们表示不会在那里修复它：

---

他们在2018年重新引入了发送目的：预回迁头和所有nostate预回迁请求，正如上次对此问题的评论所述

强调：“当预渲染发生时，Chrome不会传递任何明显的标题”，这基本上回答了我的问题。在请求主体时，根本不使用预取HTTP头。我认为需要明确的是，预呈现和预取不是一回事。默认情况下，在主要浏览器中，预抓取处于启用状态，并且始终由一个特殊的标题指示（

X-Purpose:preview

在Chrome中）。预渲染是一种实验性的Chrome功能，开发者必须选择使用它。没有用于检测预呈现的标题，因为开发人员知道他们是否打开了它。@krispy-实际上，即使开发人员没有选择加入（例如，当用户在url栏中键入时），预呈现也会发生。对我们来说，这是一个令人讨厌的错误的原因。检测此AFAIK的唯一方法是通过页面可见性API，因此不可能在服务器端检测到它。在我看来，他们真的应该在这种情况下设置一个http头（他们没有这样做）。@UpTheCreek自我发布该消息以来，预渲染的选择性加入性质很可能已经改变。也就是说，我相信预渲染只能通过GET请求进行。因此，Chrome预取API调用导致的错误可以通过遵守HTTP标准和不执行GET请求导致的操作来避免。GET请求仅用于获取数据。其他操作存在POST、PUT和DELETE。请注意，我并不是说您的bug与此相关。我只是为了那些在构建API时可能会遇到此问题的人而提到它。@krispy:获取数据会消耗资源，并且如果请求的格式不正确（例如错误的查询字符串），可能会导致在服务器端生成错误消息。这是可笑的自动执行这一点，并没有绝对的方式来表明它。这也是对Chrome用户带宽的严重滥用。