Lambdaプロキシ統合にてダウンロードしたPDFが壊れてしまう

Question

前提

AWSのAPIGatewary＋Lambdaを使用してPDFファイルのダウンロード機能を実装しています。

• APIGatewaryとLambdaは、Lambdaプロキシ統合にて連携
• APIGatewayの設定にある「バイナリメディアタイプ」に application/pdf を追加
• CloudFrontを使用

発生している問題・エラーメッセージ

クライアントのWebシステムから対象APIGatewayのURLにてダウンロードを実行した際、作成されるPDFファイルが壊れていると言われ開けません。

APIGatewayの設定にある「バイナリメディアタイプ」を */* とすることで、正常なダウンロードとなることは確認できました。
但し、これだと他APIで行っているJSON受信がおかしくなってしまうので問題があります。

＜追記＞
CloudFrontを経由しなければ、問題は発生しませんでした。

該当のソースコード

exports.handler = async (event) => {
  try {
    const contentType = "application/pdf"
    const buffer = "＜ここにはPuppeteerでPDFを作成した結果の文字列が設定される＞"

    const base64 = buffer.toString("base64")
    return {
        "statusCode": 200,
        "headers":{
            "Access-Control-Allow-Origin": "*",
            "Access-Control-Expose-Headers" : "Content-Disposition",
            "Content-Length": Buffer.byteLength(base64),
            "Content-Type": contentType,
            "Content-Disposition": "attachment; filename=download.pdf"
        },
        "isBase64Encoded": true,
        "body": base64
    }
      
  } catch (error) {
    console.log(error)
    throw error

  }
  
}

試したこと

• 前述の通り「バイナリメディアタイプ」を */* とすることで、正常なダウンロードができた
• Lambda側の「Content-type」とAPIGatewayの「バイナリメディアタイプ」を application/octet-stream としたがダメだった
• CloudFrontのビヘイビア設定にて、ダウンロードのURLについてのみ設定を色々変えてみたが上手くいく設定をみつけられなかった

解決したいこと

指定したメディアタイプ（PDF）のみ上手く処理されるようにしたいのですが、原因と対策がわからず困っております。

＜追記＞
CloudFrontの設定で何か不足・対策が必要なのかもしれません。
何かご存知の方はコメントください。

Answer 1

以下の二つを実施して解決しますか？

1. クライアントからAPI Gatewayをリクエストする時、リクエストヘッダーにAccept:application/pdfを指定

2. API Gatewayの該当のPathに以下の設定を入れる

・HTTPのステータスを追加
・200のレスポンス本文→コンテンツタイプを以下に設定
application/pdf

Comments

[plasticgrammer]

回答ありがとうございます。
レスポンスのコンテンツタイプを指定する際に『モデル』を選択する必要があるようなのですが、どのようなモデルを作成しておけば良いのかわかりますでしょうか。

[plasticgrammer]

追記です。
リクエストヘッダーへのAccept:application/pdfの追加だけではうまくいきませんでした。

[tamanegine]

モデルに関してはemptyを選択して見てください

[plasticgrammer]

試してみましたが、同様にpdfが壊れているエラーとなってしまいました。
APIのデプロイも忘れずにできていると思います。

[plasticgrammer]

質問へ条件を追加しました。
CloudFrontの設定で何か不足・対策が必要なのかもしれません。
何か想定される原因がありましたらコメントください。

[tamanegine]

すみません返信が遅くなりました
API Gatewayの前にCloudfrontを挟んでいる状態でしょうか？
その場合リクエストヘッダーのAcceptをOriginに転送するかCloudfrontがヘッダーをセットしてoriginに転送するようにしていますか？
また念の為ですが、Lambdaのペイロードサイズが6MBまでですがPDFファイルはbase64にした状態で6MBを超えていないでしょうか?
base64にするとおよそ133%容量が増加します
https://developer.mozilla.org/ja/docs/Glossary/Base64

[plasticgrammer]

回答を参考にCloudFrontにて「Legacy cache settings」の「ヘッダーを追加」にてAcceptを追加したところ、上手く動くようになりました。ご回答ありがとうございました。

何度か試行したなかで、すべてのヘッダーを許可するように
「Cache policy and origin request policy (recommended)」のほうで、「オリジンリクエストポリシー」にAllViewer を設定してもダメでした。
これは理解が間違っているのか、上手くいくはずなのかどちらなのでしょうか。
こちらについても何か情報がありましたらコメント頂けると助かります。

[tamanegine]

無事上手く行って良かったです。

> 「Cache policy and origin request policy (recommended)」のほうで、「オリジンリクエストポリシー」にAllViewer を設定
こちらで動くかと思いますが
・キャッシュポリシーにより、オリジンに転送されずキャッシュに残っている壊れたレスポンスを返した
・Cloudfrontの設定反映が終わっていないときに確認した（およそ5分かかります）
が考えられると思います

[plasticgrammer]

コメントありがとうございました。

追加で調べていくと、オリジンリクエストポリシーではAuthorizeは転送されないという記載がありました。
確かに「Cache policy and origin request policy (recommended)」だと、壊れているというよりはリクエストを受け付けない挙動だったように思えます。
ここら辺をもう一度理解し直して、チャレンジしてみます。サポートありがとうございました。