Question

我将Api网关端点设置为HTTP_PROXY，并且按预期工作 - 只要您不提供Accept-Encoding: gzip标头。然后就失败了。似乎Api Gateway正在对响应进行“某种操作”，这使得它在接收端无法解读。

这就是我所看到的：

直接向代理后端发送请求按预期工作（例如curl --compressed成功完成）。
使用curl --compressed（以及其他方式）通过Api网关发送请求会导致“无效的阻止类型”。
来自代理服务器的响应是17514字节，而通过Api网关，它已被炸毁到31506字节。这反映在Content-Length标题中。
Api Gateway包含带有旧（正确）值的x-amzn-Remapped-Content-Length标头，因此它似乎知道它对响应做了某些事情。

API方法配置为HTTP PROXY，如下所示：

aws apigateway get-method --rest-api-id xxxxx --resource-id yyyyy --http-method POST

{
  "requestModels": {
    "application/json": "MyRequestModel"
  },
  "authorizationType": "CUSTOM",
  "apiKeyRequired": false,
  "httpMethod": "POST",
  "methodIntegration": {
    "passthroughBehavior": "WHEN_NO_MATCH",
    "cacheKeyParameters": [],
    "requestParameters": {},
    "uri": "http://myproxy/api/v1/resource",
    "httpMethod": "POST",
    "requestTemplates": {},
    "cacheNamespace": "zzzzz",
    "type": "HTTP_PROXY"
  },
  "requestValidatorId": "xyxyxyxy",
  "authorizerId": "zyzyzyzyz"
}

据我所知，此处没有任何内容表示代表Api Gateway的任何映射。 UI也不表示任何响应映射。

测试Api，我看到以下内容：

响应标头包含"Content-Length":"17514"，这是预期值
从日志中它似乎就像Endpoint响应体和Method响应体一样，尽管手动比较两个乱码的aszii表示gzip数据有点困难。两个Content-Length标题也相同。

在测试期间，重新映射的内容长度值在任何地方都不可见，x-amzn-Remapped-Content-Length标头也不可见。这让我怀疑这可能是由Cloudfront完成的吗？

我通过“execute-api”和我的自定义域映射得到了相同的结果。

任何指针？

Answer 1

正如迈克尔在他的一篇（非常有帮助的）评论中所怀疑的那样 - 这确实是API Gateway将我的gzip流视为UTF-8编码文本并重新编码的情况。鉴于这是一个没有设置集成响应映射的端点，API Gateway会以任何方式处理我的响应，这似乎非常违反直觉，但在文档中提到了它。

解决方案是告诉API Gateway，对于此REST API，application/json内容类型是＆＃34;二进制数据＆＃34;。这会导致API Gateway在未处理的情况下传递响应。然而，指示REST API使用Cloudformation执行此操作本身就是一个漏洞，这是解决方案：

RestApi:
  Type: 'AWS::ApiGateway::RestApi'
  Properties:
    Name: !Sub 'agraNcdx${Environment}'
    BinaryMediaTypes:
      - 'application~1json'

AWS Api Gateway代理压缩“无效块类型”

1 个答案: