时间戳

首页 > 解决方案 > 无法设置 aws api 网关以使用 gzip 编码的集成端点

curl - 无法设置 aws api 网关以使用 gzip 编码的集成端点

问题描述

我正在尝试在我的服务端点上启用 gzip 压缩。我原来的休息服务是一个spring boot web应用程序。由于这个答案，我很容易启用了 gzip。

当我尝试将它与 AWS 公共 api 集成时，问题就开始了。我正在使用招摇集成。

如果我不对公共 api 执行任何操作，则通过邮递员或 curl 向公共 api 发出的请求永远不会返回编码响应或与编码相关的标头。

因此，我尝试通过Accept-Encoding应用特定示例映射将请求标头通过公共 api 传递给我的原始休息服务，如下所示：

{
    "/brand/list": {
        "get": {
            "summary": "Get a list of brands",
            "description": "List",
            "operationId": "List",
            "produces": [
                "application/json",
                "application/x-www-form-urlencoded",
                "text/plain"
            ],
            "parameters": [
                {
                    "name": "Accept-Encoding",
                    "in": "header",
                    "required": false,
                    "type": "string"
                }
            ],
            "responses": {
                "200": {
                    "description": "OK",
                    "schema": {
                        "$ref": "#/definitions/DataModelOfBrandCatalogue"
                    },
                    "headers": {
                        "Content-Encoding": {
                            "type": "string"
                        }
                    }
                },
                "400": ..., ...., "500"
            },
            "x-amazon-apigateway-integration": {
                "uri": "http://original.service.com/brand/list",
                "responses": {
                    "200": {
                        "statusCode": "200",
                        "responseParameters": {
                            "method.response.header.Content-Encoding": "integration.response.header.Content-Encoding"
                        }
                    },
                    "400": ..., ...., "500"
                },
                "requestParameters": {
                    "integration.request.header.Accept-Encoding": "method.request.header.Accept-Encoding",
                    "integration.request.header.Content-Type": "'application/json'"
                },
                "passthroughBehavior": "when_no_match",
                "httpMethod": "GET",
                "type": "http"
            },
            "tags": []
        }
    }
}

虽然当我部署此描述时，会发生一些有趣的事情。当我执行如下所示的 curl 请求时，响应确实被编码。如果我Accept-Encoding从 curl 中删除参数，则响应不会按预期编码。到这里为止一切都很好。

curl -X GET   https://api.service.com/brand/list   -H 'Cache-Control: no-cache'   -H 'Accept-Encoding: gzip'

但是当我去邮递员并进行相同的查询时（我确信它们是相同的，因为我通过邮递员自己的工具 -code按钮生成了 curl 命令）它没有得到任何响应。邮递员控制台显示Error: incorrect header check。

我错过了什么？我的策略错了吗？还是我错过了一些细节？

编辑：我认为编码的响应是正确的，但是当我添加--compressed到我的curl请求时，我注意到它在下面给出了错误，所以编码也不正确。

curl：（61）处理内容未编码时出错：无效块类型

标签： curlpostmanaws-api-gatewayswagger-2.0

解决方案

由于集成响应负载（来自您的服务端点）已经被压缩，您应该让 API Gateway 知道它是二进制的。

以前，您只能通过在 API 设置中明确设置二进制媒体类型来做到这一点。您可以对所有媒体类型使用特定的媒体类型，例如“application/json”或“ / ”。如您所料，有一个缺点。现在无论是否压缩，它都会将内容视为二进制。

最近推出了一项更新，当响应的“Content-Encoding”标头的值不是“identity”时，将集成响应作为二进制隐式处理。例如，如果您的响应包含“Content-Encoding: gzip”，那么 API Gateway 会将其作为二进制处理，而无需任何明确的二进制媒体类型设置。

但是，当您使用 HTTP 集成时，此行为仅适用于 Lambda/HTTP 代理集成。您可以在其上设置二进制媒体类型或切换到 HTTP 代理集成以获得隐式二进制支持的好处。如果您不使用响应正文模板之类的功能，我推荐后者。

推荐阅读