Gateway#AWS若槻龍太2021.10.13この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。IoT事業部の若槻です。GatewayバックのLambda関数にアプリケーションからカスタムヘッダーを渡す際にハマったので対処した話です。CDKで実装しました。}}LambdaコードLambdaではカスタムヘッダーdeviceIdが指定されていればステータスコード200、未指定ならステータスコード400を返します。Gatewayコンソールで動作確認をしてみます。deviceIdヘッダーを指定した場合は200が返ります。deviceIdヘッダーを指定しない場合は400が返ります。コンソールからはちゃんと動作していることを確認できました。APIにリクエストをする下記のReactアプリを実装しました。App;ハマり1:Access-Control-Allow-Headersへの未追加アプリにブラウザでアクセスすると下記のエラーとなりました。response.APIへのプリフライトリクエストに対するAccess-Control-Allow-Headersレスポンスヘッダーにdeviceidが追加されている必要があるようです。MDNプリフライトリクエストとは、ブラウザからのCORSリクエストがCORSプロトコルに則っているかどうかをAPIサーバーがチェックするためのリクエストです。MDNそこでCDKコードを下記のように修正します。APIに対して再度アプリからアクセスすると、次は400エラーとなりました。Lambdaのログを確認するとデバイスIDヘッダーがdeviceIdではなくdeviceid(小文字のみ)となっています。そのためLambdaが400エラーをレスポンスしていたようです。ブラウザのネットワークログを確認すると、ブラウザからのリクエスト時点でdeviceidとなっています。ドキュメントによるとHTTPヘッダーは大文字と小文字を区別しない(case-insensitive)とのこと。そのためリクエスト時にヘッダーが小文字のみのdeviceidに変換され、Lambda側で大文字含むdeviceIdをパースできなかったようです。そこでLambdaコードを下記のようにヘッダーを小文字で扱うように修正します。console.log('deviceIdが指定されていません');するとエラー無くリクエストを実行することができました。バックエンドのE2Eテストでは問題を見つけられなかった今回ハマった事象ですが、バックエンドを実装した際に作成したE2Eテストでは問題を見つけられませんでした。APIにリクエストをするのですが、今回ハマった事象はブラウザでアクセスすることが条件であったためです。よってアプリケーションを実装する際に初めて問題が見つかった、という経緯がありました。GatewayバックのLambda関数にアプリケーションからカスタムヘッダーを渡す際にハマったので対処した話でした。Webの基本的なところの理解がまだまだだということを思い知らされました。ブラウザを使うことを前提としたより本番利用に近い形でのテストを実装する必要性も感じました。