【发布时间】：2017-06-05 00:02:57
【问题描述】：
看来我的问题可能有点类似to this one。
我的 API Gateway 中有一个 API，并且正在通过 HTTP 代理到 POST 的 multipart/form-data 文件的端点。
如果我直接调用 HTTP 端点（不是通过 API gateway） - 使用 postman，它会按预期工作，但是，使用 API 网关端点（通过 postman）会失败。
我比较了两个请求（通过fiddler 和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 网关的请求（无效）：
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），但正如您在请求中看到的那样，它就在那里。
有什么想法吗？
编辑 在同一 APIGateway POST 上来自 CloudWatch 的日志
错误仍然是 400 - 找不到文件
【问题讨论】：
-
您好，我遇到了完全相同的问题。还没有得到解决方案。你有什么发现吗？我在 aws api 网关中使用了二进制类型。仍然是同样的问题。我没有使用 lambda，而是直接 api 网关到 http 代理直通。
-
@MihirShah - 是的，如 cmets 中所述。我通过使用 S3 签名 URL 解决了这个问题——它们很简单，事后看来真的很有用。或者，您可以尝试以下其他答案之一，但是，我认为使用具有此功能的 S3 非常适合。
标签： amazon-web-services aws-lambda aws-api-gateway