0

我们有一个实时的谷歌云函数，它本质上是使用一个非常简单的 Python 脚本从一个现已失效的站点为我们返回正确的重定向，由一个缓存响应的 CDN 支持，以避免不必要地触发该函数。

我们对函数本身的工作方式没有任何问题，但是我们注意到，为了响应与请求一起传递的特定用户代理 (Bingbot)，Google Cloud Function 将Cache-Control: Private标头注入到响应中，而与功能代码（它没有在它发回的 301 响应中指定 Cache-Control 标头）。这导致来自 Bingbots 的所有请求每次都被传递到后端，导致我们的云功能使用率比平时高得多，并产生更高的成本。

这也会导致内容和传输编码的变化，尽管我们不太关心这一点。

我们通过在向后端（函数）发出请求之前在 CDN 级别剥离 User-Agent 标头来测试这一点，并确认没有 Bingbot 标头，我们得到 0 个持久通过；让头球回过头来重新产生了比我们应该看到的传球次数多得多的问题。

此时我们已经开始剥离所有 User-Agent 标头，这在浅薄的基础上解决了问题，但我们担心这是未记录的行为，并且我们不知道 Cloud Functions 何时可能在其他情况下注入或操纵响应标头响应请求标头。

为了确认这不是来自我们的 Python 脚本，返回我们响应的相关部分如下：

try:
     return flask.redirect(redirect_dict[request.path], code=301)
except:
     return flask.redirect(os.environ.get('FALLBACK_URL'), code=301)

使用 Bingbot UA 进行卷曲（实际 URL 和主机被隐藏）：

curl -v -X GET $function/$path -H 'User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)' -H $host

以及相关回应：

< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=utf-8
< Function-Execution-Id: jzlrm3k4ndhv
< Location: $redirectURL
< X-Cloud-Trace-Context: 83841aa8390d4ea4c1c8349c3aca21be
< Content-Encoding: gzip
< Date: Mon, 20 May 2019 13:02:22 GMT
< Server: Google Frontend
< Cache-Control: private
< Alt-Svc: quic=":443"; ma=2592000; v="46,44,43,39"
< Transfer-Encoding: chunked

如果没有 Bingbot UA，则响应为：

< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=utf-8
< Function-Execution-Id: t8frc9wsdvzp
< Location: $redirectURL
< X-Cloud-Trace-Context: 1f817eecdc84ad4a7542fba5898caf50;o=1
< Date: Mon, 20 May 2019 13:02:37 GMT
< Server: Google Frontend
< Content-Length: 319
< Alt-Svc: quic=":443"; ma=2592000; v="46,44,43,39"

我们希望响应与我们没有注入任何缓存控制标头来响应查询相同。明显改变用户代理会导致 Google Cloud Functions 注入额外的标头、改变编码和以其他方式转换响应。令人担忧的是，没有关于此的文档或其他信息（除非我错过了它）。如果有人能指出我的任何解释，或者谷歌的人可以解释为什么会发生这种情况以及我们可以用来防止它的任何其他设置，那将是这里的理想结果。

4

0 回答 0