Azure 函数弄乱了 gzip 后的 POST 数据答案

【问题标题】：Azure functions messing up gzipped POST dataAzure 函数弄乱了 gzip 后的 POST 数据
【发布时间】：2020-09-12 06:29:00
【问题描述】：

目前我正在实现一个 webhook，它指出发送到配置的端点的请求将被压缩，我遇到了一个奇怪的错误。

我创建了一个中间件来处理请求数据的解压缩：


  const buffer: Buffer[] = [];

    request
      .on("data", (chunk) => {
        buffer.push(Buffer.from(chunk));
      })
      .on("end", () => {
        const concatBuff: Buffer = Buffer.concat(buffer);

        zlib.gunzip(concatBuff, (err, buff) => {
          if (err) {
            console.log("gunzip err", err);
            return next(err);
          }
          request.body = buff.toString();
          next();
        });
      });

我在所有其他正文解析器中间件之前添加了这个中间件，以避免与之不兼容。

所以我用这个 curl 命令测试它：

cat webhook.txt | gzip | curl -v -i --data-binary @- -H "Content-Encoding: gzip" http://localhost:3334

在这个使用azure-function-express的服务器中，我收到了这个错误：

[1/9/2020 22:36:21] gunzip err Error: incorrect header check
[1/9/2020 22:36:21]     at Zlib.zlibOnError [as onerror] (zlib.js:170:17) {
[1/9/2020 22:36:21]   errno: -3,
[1/9/2020 22:36:21]   code: 'Z_DATA_ERROR'
[1/9/2020 22:36:21] }
[1/9/2020 22:36:21]

似乎是因为header不是gzip文件的“魔数”造成的：

1f ef bf bd 08 00 ef bf bd ef bf bd 4e 5f 00 03 ef bf bd 5d 6d 73 db b8 11 ef bf bd ef b f bd 5f ef bf bd e1 97 bb 6b 7d 16 ef bf bd 77 ef bf bd 73 ef ... 4589 更多字节>

但奇怪的是，我创建了一个新的 express 应用程序来使用完全相同的 curl 进行测试，并且它在那里完美运行，所以 createAzureFunctionHandler 似乎存在一些问题，或者我错过了什么。

你们在使用 Azure 函数时遇到过这些问题吗？

你知道 Azure 搞砸了 gzip 数据吗？

【问题讨论】：

你能否在你的 curl 请求中设置 Content-Type: application/octet-stream 标头并检查
@KrishnenduGhosh-MSFT 似乎更改它可以修复错误，但是我无法控制 Conent-Type，因为它是由另一个系统发送的。您知道为什么将其设置为 application/json 崩溃吗？
从技术上讲，将 Content-Type 设置为 application/octet-stream 的意思是“我不知道这个二进制文件是什么意思，随手拿它，不要乱用它”。在函数 http 触发器中，如果内容类型不是 application/octet-stream 或以“multipart”开头，它会尝试读取为字符串，如果未正确指定编码可能会混乱。周围有一个open issue。对于您的情况，请尝试在 function.json 的 http 触发器中设置“dataType”：“binary”。 (1/2)
我刚得到 Azure 的答复，他们告诉我使用 Azure 代理，所以我得到了它的使用
如果我没记错压缩是为了压缩响应，我想解压缩从 webhook 发送给我的请求正文，谢谢你的帮助！

标签： node.js typescript azure express azure-functions

【解决方案1】：

我刚得到 Azure 团队的答复，他们建议我在 proxies.json 中设置一个代理作为解决方法，所以如果有人遇到同样的问题，您可以设置一个新的代理来覆盖 Content-Type。

在我的情况下，我一直期待一个 gzip 压缩的 json，所以如果你事先不知道这是哪种类型，这可能不适合你。

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "RequireContentType": {
            "matchCondition": {
                "route": "/api/HttpTrigger"
            },
            "backendUri": "https://proxy-example.azurewebsites.net/api/HttpTrigger",
            "requestOverrides": {
                "backend.request.headers.content-type": "application/octet-stream",
                "backend.request.headers.request-content-type": "'{request.headers.content-type}'"
            }
        }
    }
}

【讨论】：