Google 负载均衡器或存储桶返回 304 而不是 404 状态码

Question

我们在 Google 存储桶前面有一个 Google 负载均衡器，不涉及 CDN。从存储桶中删除资源时，负载均衡器（或存储桶）在删除 7 小时后一直返回“304 - 未修改”。我在 Google 跟踪器上打开了一个问题，他们说这不是错误，有人可以解释这是正确的行为吗？

这个问题是我们使用谷歌负载均衡器 + 谷歌存储来托管一个网站：googlebot 爬虫广泛使用 if-modified-since 标头，当对象从存储桶中删除时它会得到错误信息，因此它会不断索引它们并且然后用户点击谷歌搜索上的链接，将他们发送到网站上不再存在的页面。

--- 更新了 curl 和 HTTP 响应 --------------

将html页面添加到存储桶后的初始请求：

curl -I https://[...removed...]/aPageToBeDeletedSoon.html

响应是 200:

HTTP/2 200
x-guploader-uploadid: ADPycdv0e1G0szqPyxG4ysjaAENeIpd9FfqnZIgKvSO75HPmkSzV_b0fuGjWvnthxBAeW        OgYTRZBUGW_eK7qldWVsvyx4zI7WGOe
expires: Wed, 19 Apr 2023 21:28:12 GMT
date: Wed, 19 Apr 2023 20:28:12 GMT
cache-control: public, max-age=3600
last-modified: Wed, 19 Apr 2023 20:16:33 GMT
etag: "872b56ac0833cab70268fafd56977d27"
x-goog-generation: 1681935393381003
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 324
content-type: text/html
content-language: en
x-goog-hash: crc32c=giMpfg==
x-goog-hash: md5=hytWrAgzyrcCaPr9Vpd9Jw==
x-goog-storage-class: STANDARD
accept-ranges: bytes
content-length: 324
server: UploadServer
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

然后删除页面，没有条件 GET 的相同请求：

curl -I https://[...removed...]/aPageToBeDeletedSoon.html

响应正确 404:

HTTP/2 404 
x-guploader-uploadid: ADPycdu7aypcXTmemsyc7O6dm4y87qOVI7vHM83XWwoOhmz2hpKcp9EgBPzr1qCYDNZSS1kcrYiSWtA3diKm0T2NrZ5I1OXs0YKo
expires: Wed, 19 Apr 2023 21:32:42 GMT
date: Wed, 19 Apr 2023 20:32:42 GMT
cache-control: public, max-age=3600
last-modified: Wed, 19 Apr 2023 16:24:02 GMT
etag: "872b56ac0833cab70268fafd56977d27"
x-goog-generation: 1681921442904030
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 324
content-type: text/html
content-language: en
x-goog-hash: crc32c=giMpfg==
x-goog-hash: md5=hytWrAgzyrcCaPr9Vpd9Jw==
x-goog-storage-class: STANDARD
accept-ranges: bytes
content-length: 324
server: UploadServer
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

然后几分钟后，带有 if-modified-since 条件的相同请求：

curl -I --header 'If-Modified-Since: Wed, 19 Apr 2023 21:28:12 GMT'  https://[...removed...]/aPageToBeDeletedSoon.html

响应是 304-Not Modified:

HTTP/2 304 
x-guploader-uploadid: ADPycdu4tSoSlopfNXh0TcZ63BaMBn_CQ4bmerrzIHaaopUBiH4CGUc0oZfhonX1baZzjyupzSL0PNz5BQs2Y4Ls_KCKig
expires: Wed, 19 Apr 2023 21:35:54 GMT
date: Wed, 19 Apr 2023 20:35:54 GMT
cache-control: public, max-age=3600
last-modified: Wed, 19 Apr 2023 16:24:02 GMT
etag: "872b56ac0833cab70268fafd56977d27"
content-type: text/html
server: UploadServer
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

此负载均衡器后端未启用 CDN，我注意到至少在对象被删除一天后发生这种情况。

Answer 1

我们在这方面取得了一些进展，我将开始回答我自己的问题，也许有人可以填补空白。我们仍在寻找解决方法或了解我们是否错误配置了 Google Cloud 设置。顺便说一句，使用 Firebase 托管的测试如我们预期的那样工作（即不同于我们的 Google Storage+Load Balancer 设置）：使用 Firebase 每当从托管网站中删除对象时，它总是在 if-modified-since 请求中返回 404并且独立于我们发现影响 Google Storage 响应的任何其他设置/标头。我将在下面详细说明我们的发现。顺便说一句，由于负载平衡要求，Firebase 托管不是我们的选择。

发现 #1：使用 Google 存储，如果对象不存在并且存储桶在网站配置设置中配置了错误页面，则根据错误页面上次修改日期验证 if-modified-since 日期条件，并且然后它返回304代码+错误页面的最后修改日期+错误页面的etag（在错误页面专门针对404代码的设置中）。我们的存储桶需要保持 404 错误页面的配置，我们没有删除它的选项。现在，上面描述中的原始测试有点误导，因为纯属巧合，我复制了 404 页面来为测试创建一个新对象，所以在两个响应中，200 响应和 304 响应你看到相同的 etag，但它们应该是不同的。

发现 #2：Google Chrome 在对同一页面的后续请求中，还会传递 if-none-match 标头，告诉服务器检查 etag 是否已更改。 Google Storage 在使用该附加标头请求时，会在请求已删除对象时向浏览器返回 404，因为错误页面 etag 与已删除对象 etag 不同。我想除了 Chrome 之外的所有其他浏览器都使用相同的技术（或者另一种选择是在 etag 不匹配的情况下它们与服务器进行另一次往返）。

我们的问题是 googlebot 在抓取存储桶时不使用 if-none-match 标头，即使它获得了不同的 etag 和之前抓取的对象的不同上次修改日期，我们也看不到它尝试在没有 if-modified-since etag 的情况下执行另一个往返请求以验证它是否已被删除，或者假设该对象已被删除，因为 etag 不同并停止抓取它：删除后我们看到相同的资源是googlebot 仍然每天两次请求，我们的网站始终以 304 响应。 googlebot 可能有某种非常延迟（可能几天后）的过程来清理 etag 不匹配的对象的索引，但如果该清理过程没有发生，我担心 googlebot 可能会标记该网站不真实当前内容是什么。

此时我不确定这是关于 googlebot 行为还是 Google Storage+Load Balancer 配置的问题。