web-dev-qa-db-ja.com

API Gateway-multipart \ form-dataの投稿

私の質問は多分少し似ているようです これに 。

API Gateway内にAPIがあり、POSTのmultipart/form-dataファイルのエンドポイントまでHTTPプロキシを実行しています。

Httpエンドポイントを（APIゲートウェイ経由ではなく）直接呼び出す場合-postmanを使用すると、期待どおりに動作しますが、APIゲートウェイエンドポイント（postman経由）の使用は失敗します。

同じように見える両方のリクエストを（フィドラーとCloudWatchログを介して）比較しました：

直接API呼び出しのリクエスト（動作中）：

POST https://domainname/api/v1/documents HTTP/1.1
Host: api.service
Connection: keep-alive
Content-Length: 202
Authorization: AuthToken
Postman-Token: a75869d6-1d64-6b9f-513d-a80ac192c8e1
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
docMetaInfo: some extra data needed
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryB85rsPlMffA2fziS
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8

------WebKitFormBoundaryB85rsPlMffA2fziS
Content-Disposition: form-data; name=""; filename="Test.txt"
Content-Type: text/plain

This is a test Text File
------WebKitFormBoundaryB85rsPlMffA2fziS--

API Gatewayからのリクエスト（機能していない）：

POST https://GATEWAY_domainname/api/v1/documents HTTP/1.1
Host: api-Gateway.service
Connection: keep-alive
Content-Length: 202
Authorization: AuthToken
Postman-Token: e25536fa-3dfa-ddcb-8ca6-3f3552d2bc40
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
docMetaInfo: some extra data needed
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarybX9MyWBsuLGm6QIC

x-api-key: *********************
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8

------WebKitFormBoundarybX9MyWBsuLGm6QIC
Content-Disposition: form-data; name=""; filename="Test.txt"
Content-Type: text/plain

This is a test Text File
------WebKitFormBoundarybX9MyWBsuLGm6QIC--

ゲートウェイ側からいくつかのことを試してみました。Integration Request同じコンテンツタイプの新しいボディをマップします。運はありません。

私が知っている限り、この呼び出しはpassthroughするだけでよいので、なぜそれが少し混乱しているのか-データ操作/インターセプトの必要はないのでしょうか？

私が受け取るエラーは400-不正な要求（fileが見つからないという不満）ですが、要求でわかるように、そこにあります。

何か案は？

[〜＃〜] edit [〜＃〜]同じAPIGateway POSTでのCloudWatchからのログ

enter image description here

エラーはまだ400です-ファイルが見つかりません

amazon-web-servicesaws-lambdaaws-api-gateway
22
Hexie

API Gatewayは現在、マルチパートフォームデータをサポートしていません。これは将来の開発のために検討されています。それまでの間、クライアントを変更して、複数のリクエストまたは単一のワンパートリクエストを使用する必要があります。

Update：API Gatewayはバイナリペイロードをサポートするようになりました。単にmultipart/form-dataをAPIのバイナリメディアタイプとして使用し、ペイロードをLambda関数に直接プロキシします。そこから本文を解析して、ファイルのコンテンツを取得できます。マルチパート本文の解析に役立つライブラリが利用できるはずです（たとえば、Node.jsの parse-multipart ）。

19
RyanG

まだ助けが必要な人のために、これは現在公式に文書化されています：

https://docs.aws.Amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-configure-with-console.html

要約すると、手順は次のとおりです。

  1. APIの[API Gateway設定]タブに移動し、[multipart/form-data]を[バイナリメディアタイプ]セクションに追加します。
  2. プロキシメソッドのリクエストヘッダーに「Content-Type」と「Accept」を追加します
  3. 同じヘッダーを統合要求ヘッダーに追加します
  4. 再配備

乾杯

4
Dre

私はTomcatサーバーと統合するのと同じ問題を抱えていましたが、それを修正するために必要な以下の変更を見つけました。

  1. 追加Content-Type apiのHTTP要求ヘッダーコンソールでapiゲートウェイに追加するか、次のようなオープンAPIドキュメントに追加します。

    {
    "/yourApi":{
        "post":{
            "operationId":"uploadImageUsingPOST",
            "produces":[
                "application/json"
            ],
            "parameters":[
            {
                "name":"Content-Type",
                "in":"header",
                "required":false,
                "type":"string"
            },
            {
                //Other headers
            }]   
        }
    }

  2. 上記の手順では、統合リクエストのapiのHTTPヘッダーにContent-Typeも追加します。ここに追加しない場合は、ヘッダーをもう1つ追加しますAccept = '/' =コンソールによるAPIゲートウェイで、または、次のようなオープンAPIドキュメントに追加します。

    "requestParameters":{
    "integration.request.header.Accept":"'*/*'",
    "integration.request.header.Content-Type":"method.request.header.Content-Type",
    //Other headers
}

  3. APIの統合リクエストでコンテンツ処理をパススルーとして設定します。

  4. コンソールまたは開いているAPIドキュメントを使用して、apiの設定にmultipart/form-dataをバイナリメディアタイプとして追加します。

    "x-Amazon-apigateway-binary-media-types": [
    "multipart/form-data"
]

  5. 上記の変更を、画像をマルチパートとしてアップロードする予定のステージにデプロイします。

APIゲートウェイは、マルチパートファイルをバイナリ配列として渡しますが、コントローラーで@RequestBody MultipartFile multipartFileを引き続き使用でき、Springはこのバイナリをマルチパートに解析します。

1
Swalih

変更があったようで、API GatewayはContent-Typeヘッダー値全体の厳密なマッチングを行わないため、「バイナリ」サポートのすべてが期待どおりに機能するようになりました。

APIをPOST（またはPUT）に設定し、Lambda統合を「プロキシ」に設定します。APIの設定に移動し、「バイナリ」として使用するメディアタイプを追加します。 multipart/signedを追加しました。実際に受信したメディアタイプはContent-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="----54645645645664564563424768"です。

API GWはこれを「バイナリ」として引き続きピックアップし、base64としてLambdaに配信します。

ラムダでこれをキャッチします：

Context:
{
  "callbackWaitsForEmptyEventLoop": true,
  "logGroupName": "/aws/lambda/api-invoice",
  "logStreamName": "2018/04/27/[$LATEST]3454",
  "functionName": "api-invoice",
  "memoryLimitInMB": "128",
  "functionVersion": "$LATEST",
  "invokeid": "345-49e2-11e8-34-345",
  "awsRequestId": "345-49e2-11e8-34-345",
  "invokedFunctionArn": "arn:aws:lambda:eu-west-1:12345:function:api-invoice"
}
-------
Event:
{
  "resource": "/peppol/as2",
  "path": "/peppol/as2",
  "httpMethod": "POST",
  "headers": {
    "Accept": "*/*",
    "AS2-From": "PEPPOL_AP",
    "AS2-To": "234567890",
    "AS2-Version": "1.1",
    "cache-control": "no-cache",
    "Content-Type": "multipart/signed; protocol=\"application/pkcs7-signature\"; micalg=\"sha256\"; boundary=\"----54645645645664564563424768\"",
    "Date": "Fri, 27 Apr 2018 06:17:10 GMT",
    "Disposition-Notification-Options": "signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1,md5",
    "Disposition-Notification-To": "[email protected]",
    "Host": "123.execute-api.eu-west-1.amazonaws.com",
    "Message-ID": "<[email protected]>",
    "MIME-Version": "1.0",
    "Postman-Token": "ert-59c1-45656-94d1-456546",
    "Recipient-Address": "as2s://123.execute-api.eu-west-1.amazonaws.com/dev/peppol/as2",
    "Subject": "234567890;PEPPOL_AP",
    "User-Agent": "PostmanRuntime/7.1.1",
    "Via": "1.1 ert-",
    "X-Amzn-Trace-Id": "Root=1-4556-ertfd6554",
    "X-CLIENT-IP": "172.17.0.1",
    "X-Forwarded-For": "xx.xxx.xx.80",
    "X-Forwarded-Port": "443",
    "X-Forwarded-Proto": "https"
  },
  "queryStringParameters": null,
  "pathParameters": null,
  "stageVariables": null,
  "requestContext": {
    "resourceId": "80r6gp",
    "resourcePath": "/peppol/as2",
    "httpMethod": "POST",
    "extendedRequestId": "sdsdd343434=",
    "requestTime": "27/Apr/2018:06:17:11 +0000",
    "path": "/dev/peppol/as2",
    "accountId": "123",
    "protocol": "HTTP/1.1",
    "stage": "dev",
    "requestTimeEpoch": 1524809831262,
    "requestId": "354-49e2-3445-b2ba-535345",
    "identity": {
      "cognitoIdentityPoolId": null,
      "accountId": null,
      "cognitoIdentityId": null,
      "caller": null,
      "sourceIp": "xx.xxx.xx.80",
      "accessKey": null,
      "cognitoAuthenticationType": null,
      "cognitoAuthenticationProvider": null,
      "userArn": null,
      "userAgent": "PostmanRuntime/7.1.1",
      "user": null
    },
    "apiId": "123"
  },
  "body": "VGhpcyBpcyBhbiBTL01/ [snip] /S0NCg==",
  "isBase64Encoded": true
}
1
Anders