amazon-web-services - AWS API GATEWAY 配置以从 lambda 返回二进制 pdf 文件

Question

我想从 AWS Lambda 函数返回一个 pdf，我使用 API Gateway 从任何浏览器调用它。

我在 c# 中有一个 aws lambda 函数，它返回一个 API 网关响应，其正文是 base64 编码字符串 中的 pdf。

到目前为止，端点返回一个扩展名为 .pdf 的文件，但不是二进制文件。相反，是一个包含 base64 字符串的文本文件。

我从 C# 代码返回的 header 是:

  var headersDic = new Dictionary<string, string>();
      headersDic.Add("Content-type", "application/pdf");
      headersDic.Add("Content-disposition", "attachment; filename=file.pdf");

我手动将 base64 字符串转换为二进制文件并将其作为 pdf 文件打开，它有效，我的意思是，base64 字符串是正确的，所以我认为问题出在 API 网关上。

在API网关的集成响应控制台中，我得到了这个:

但我无法让它工作。

我还启用了二进制媒体类型。

Answer 1

实际上，您不必禁用 Lambda 代理集成，也不必将“*/*”指定为二进制媒体类型，也不必让 Lambda 代码将输出转换为 Base64，也不必必须修改 LambdaEntryPoint 才能使其正常工作。

虽然一些来源表明“*/*”条目是必要的，但答案在于二进制媒体类型设置的注释中:

"API Gateway will look at the Content-Type and Accept HTTP headers todecide how to handle the body."

换句话说，出于某种奇怪的原因，网关在应用二进制媒体类型列表时不仅仅关注返回的 Content-Type，还会考虑请求客户端的 Accept header 。大多数客户端默认为 Accept:*/*，这就是变通方法的来源，也是为什么此列表似乎不起作用的最常见解释。不仅客户端的 Accept header 似乎比此处返回的 Content-Type 值更可信，而且没有“*/*”的语义评估。它不被评估为通配符，应该匹配任何内容类型。因此，二进制媒体类型列表中最终需要所述值的精确匹配，即字面上的“*/*”。

一个简单的解决方案(对我有用的)是:

• 让客户端指定实际预期的 MIME 类型，而不是在其 Accept header 中指定“*/*”。 (不要指定多个 Accept 类型，因为只会评估第一个列出的类型。)
• 在二进制媒体类型列表中包含相同的 MIME 类型。不要指定“*/*”。
• 让 Lambda 函数返回一个非 Base64 编码的二进制文件，并在 Content-Type header 中指定其实际的 MIME 类型。例如，在 C# 中，通过从 ControllerBase.File() 方法返回一个 FileContentResult，指定适当的 MIME 内容类型，如:

return File(pdfContents, "application/pdf"); //pdfContents contains raw binary data

API Gateway 会将数据类型与其二进制媒体类型列表进行匹配，并将返回的数据视为二进制。到目前为止，我不需要在 LambdaEntryPoint.Init() 中插入 RegisterResponseContentEncodingForContentType()。