Question

当我尝试请求aws api网关时，浏览器在响应内容长度大于1024时失败。即请求在小数据上获得成功而不是大数据。

出现错误时的响应标头：

Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Accept, Cache-Control, Authorization, Credentials, UserId
Access-Control-Allow-Methods:GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Origin:*
Cache-Control:no-store, no-cache, must-revalidate, proxy-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:application/json; charset=utf-8
Date:Thu, 24 Aug 2017 15:47:53 GMT
ETag:W/"2e66-gh/gyPzUq3KxiQAslibZJg"
Expires:0
Pragma:no-cache
Surrogate-Control:no-store
Transfer-Encoding:chunked
Vary:X-HTTP-Method-Override, Accept-Encoding
X-Powered-By:Express

响应在出现错误时显示在控制台中

https://********/v1/centers net::ERR_CONTENT_DECODING_FAILED  (chrome)

SyntaxError: JSON.parse: Unexpected end of data at line 1 column 1 of the JSON data (Firefox)

成功时的响应标头

access-control-allow-headers →Origin, X-Requested-With, Content-Type, Accept, Cache-Control, Authorization, Credentials, UserId
access-control-allow-methods →GET,PUT,POST,DELETE,OPTIONS
access-control-allow-origin →*
cache-control →no-store, no-cache, must-revalidate, proxy-revalidate
content-length →838
content-type →application/json; charset=utf-8
date →Fri, 25 Aug 2017 04:44:52 GMT
etag →W/"346-I99yuNQRDTf/UvarDA7kdw"
expires →0
pragma →no-cache
status →200
surrogate-control →no-store
vary →Accept-Encoding
via →1.1 1ed35878396a5c073c88fd1b51c4f47a.cloudfront.net (CloudFront)
x-amz-cf-id →WEICithhcr5_GNYeXUUa35lvUIsicZCOnyPLdfbLm54hlS6sO3rIcw==
x-amzn-remapped-connection →keep-alive
x-amzn-remapped-content-length →838
x-amzn-remapped-date →Fri, 25 Aug 2017 04:44:51 GMT
x-amzn-requestid →224537d0-8950-11e7-ab72-bfe4c43d695f
x-cache →Miss from cloudfront
x-powered-by →Express

Api网关的Swagger json定义

{
  "swagger": "2.0",
  "info": {
    "version": "2017-08-23T06:36:43Z",
    "title": "ProxyResourceForFsApi"
  },
  "host": "**********",
  "basePath": "/v1",
  "schemes": [
    "https"
  ],
  "paths": {
    "/{proxy+}": {
      "options": {
        "consumes": [
          "application/json"
        ],
        "produces": [
          "application/json"
        ],
        "responses": {
          "200": {
            "description": "200 response",
            "schema": {
              "$ref": "#/definitions/Empty"
            },
            "headers": {
              "Access-Control-Allow-Origin": {
                "type": "string"
              },
              "Access-Control-Allow-Methods": {
                "type": "string"
              },
              "Access-Control-Allow-Headers": {
                "type": "string"
              }
            }
          }
        }
      },
      "x-amazon-apigateway-any-method": {
        "produces": [
          "application/json"
        ],
        "parameters": [
          {
            "name": "proxy",
            "in": "path",
            "required": true,
            "type": "string"
          }
        ],
        "responses": {}
      }
    }
  },
  "definitions": {
    "Empty": {
      "type": "object",
      "title": "Empty Schema"
    }
  }
}

当来自服务器的数据较少时，相同的请求成功，而当数据较大时，则失败。

Answer 1

第一个提示是：ERR_CONTENT_DECODING_FAILED。

这个失败的回复有这个：

Content-Encoding:gzip

“解码”错误是指解码编码失败。

但这有点让人分心。真正的问题在这里：

Transfer-Encoding:chunked

API Gateway显然不支持对响应进行分块传输编码。这有时也被称为“流媒体响应”。

为什么1024是错误阈值？在开始gzipping响应之前，您的后端似乎使用1024作为最小大小。这可能不是问题，除了当你的后端决定它需要gzip响应时，它也会切换到流响应。

成功的响应没有流式传输：

x-amzn-remapped-content-length →838

使用分块传输编码的流式响应不指定内容长度。

解决方案将涉及说服您的后端不要流式传输其响应，这可能意味着说服它不要gzip响应。

这可以在后端完成，但可能有一个简单的解决方法：

在集成请求中，添加值为Accept-Encoding的HTTP标头'identity'。需要'单引号，因为标头值是表达式，我们需要告诉API Gateway它是一个文字字符串。

内容长度大于1024时AWS api网关错误

1 个答案: