分块传输编码不起作用，响应完全由 GFE 缓冲

Question

Cloud 运行 / "Google Frontend" 似乎完全缓冲了来自 Cloud 运行应用程序的响应，即使在对响应使用分块传输编码时也是如此。这对增量渲染不利。

我有一个基于 com.sun.net.HttpServer 的 Java 网络应用程序，它支持响应的分块编码。特别是刷新输出流会创建一个块，所以我可以这样做：

写入响应行
同花顺
计算 10 秒
写更多回复行

在本地，这会导致分块响应：

HTTP/1.1 200 OK
Date: Sat, 07 Mar 2020 17:08:10 GMT
Transfer-encoding: chunked
Content-type: text/plain;charset=utf-8

1c
<first output>

14
<next output>

17
<next output>

0

使用 curl，我可以看到输出是递增的。

相比之下，当在云中部署相同的应用程序时运行，无论暂停多长时间（多少秒）、有多少块或有多少内容，响应都会被完全缓冲并完整返回返回（我已经测试了高达几兆字节）：

curl -v https://...
< HTTP/2 200 
< content-type: text/plain;charset=utf-8
< x-cloud-trace-context: 3872abb809e97a76298f4c46b9217656;o=1
< date: Sat, 07 Mar 2020 17:18:48 GMT
< server: Google Frontend
< content-length: 2450359

（示例有 50k 个块！）

有没有办法让 GFE 通过分块编码？

Answer 1

Cloud 运行不支持在处理请求时将数据以增量块的形式发送到客户端的流式响应。来自您服务的所有数据都作为单个 HTTP 响应发送。

此外，'Content-Length' 和 'Transfer-Encoding' headers 已从您的应用程序可能提供的响应中删除。 headers 然后由 Google 前端添加，最后提供响应。

信息来源：

1) 与 Cloud 运行工程团队的内部对话。

2) Google 云安全白皮书详细介绍了位于云运行 Managed 前面的 GFE（Google 前端）。

https://services.google.com/fh/files/misc/security_whitepapers_march2018.pdf

分块传输编码不起作用，响应完全由 GFE 缓冲

Chunked Transfer Encoding not working, response completely buffered by GFE

google-cloud-run