コンテンツの長さが1024より大きい場合のAWS apiゲートウェイエラー

Question

aws api gatewayをリクエストしようとすると、レスポンスのcontent-lengthが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": "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" 
    } 
    } 
} 

同じ要求のための

闊歩のJSON定義サーバーからのデータが少なく、それが大きくなったときに失敗した場合に成功します。

Answer 1

最初のヒントは、ERR_CONTENT_DECODING_FAILEDです。

Content-Encoding:gzip 

「デコード」エラーがエンコーディングをデコード失敗について話している：

これは、応答がこれを持っていませんでした。

しかし、それは気を散らすものです。実際の問題は次のとおりです。

Transfer-Encoding:chunked 

APIゲートウェイは明らかに応答でチャンク転送転送をサポートしていません。これは、「ストリーミング応答」と呼ばれることもあります。

なぜ1024のエラーしきい値ですか？あなたのバックエンドは、レスポンスのgzipを開始する前に最小サイズとして1024を使用しているようです。バックエンドが応答をgzipする必要があると判断した場合、ストリーミング応答に切り替えるという点を除いて、これは問題ではないかもしれません。

成功応答がストリーミングされていない：チャンク転送符号化と

x-amzn-remapped-content-length →838 

ストリーミング応答は、コンテンツ長を指定しません。

解決策には、応答をストリーミングしないようにバックエンドに納得させることが含まれます。これはおそらく応答をgzipしないように納得させることを意味します。

これは、バックエンドで行うことができるが、簡単な回避策が存在してもよい。'identity'の値を持つHTTPヘッダーAccept-Encodingを追加し、統合要求に

。ヘッダ値が式であるため、APIゲートウェイにリテラル文字列であることを伝える必要があるため、一重引用符を使用する場合は'が必要です。