API 网关 CORS HTTP 415答案

【问题标题】：API Gateway CORS HTTP 415API 网关 CORS HTTP 415
【发布时间】：2017-09-16 09:48:09
【问题描述】：

好的，我一直在这些互联网上寻找一些关于我的问题的见解；我可能已经经历了 80 多个堆栈溢出线程 RE api gateway 等，但它们似乎都没有帮助或与我的问题足够接近。

我是 API Gateway 和 cors 的新手，但让我们看看我是否可以阐明我所看到的问题：

为 Kinesis firehose 设置 API 网关代理，为 Redshift 数据库补充水分。代理、firehose 和 redshift 网关在单独调用时启动并正常工作，但从我们的一个客户站点调用时，我们收到如下错误：

XMLHttpRequest cannot load [api_call_here]. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 403.

好的，这强烈暗示需要 CORS，对吧？在资源的控制台中，启用 cors，部署，新错误：

XMLHttpRequest cannot load [api_call_here]. Request header field $cookies is not allowed by Access-Control-Allow-Headers in preflight response.

Oooooooooookay，从启用 CORS 功能添加的新 OPTIONS 方法中，在集成响应中，允许的标头，在访问控制下允许的标头添加“$Cookies”，部署。

现在我得到一个新错误，与第一个错误非常相似：

XMLHttpRequest cannot load [api_call_here]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 415.

请注意，第一个错误的 HTTP 状态代码为 403，而第三个错误的状态代码为 415。这就是我遇到问题的地方。如果我进入作为代理方法的 GET 方法，身体映射模板，我选择了“当没有定义模板时（推荐）”。

现在，我读到，当 API 网关找不到匹配的模板时，它会拒绝并返回 415 错误，因此我将上述选项更改为“当没有模板与请求 Content-Type 标头匹配时”。这使错误消失了，但是当从源调用时，数据仍然没有被持久化到红移。同样，当我直接从邮递员、失眠或只是一个普通的旧地址栏调用 api 时，记录会很好地添加。

打开 chrome 并查看标题，我看到 cookie 以 text/html 的形式出现。

关于上面的模板映射，我只为 application/json 定义了一个映射；这可能是问题的一部分吗？

另外，从 chrome 控制台查看的响应头如下：

content-length:37
content-type:application/json
date:Wed, 19 Apr 2017 23:43:35 GMT
status:415
via:1.1 [blahblabbleblah].cloudfront.net (CloudFront)
x-amz-cf-id:[blahblabbleblah]
x-amzn-requestid:[blahblabbleblah]
x-cache:Error from cloudfront

我对此比较陌生，所以我看不出云端如何适应这一点，尤其是考虑到它在抱怨媒体类型而控制台抱怨没有 access-control-allow-origin 标头。

无论如何，对于如何解决第三个错误的任何帮助将不胜感激。

【问题讨论】：

Cloudfront 为 API 网关处理一些前端物流。 API-GW 为您创建的每个 API 创建和配置隐藏的 CloudFront 分配，请求通过 CloudFront 传递到 API-GW。在这种情况下，X-Cache: Error from cloudfront 仅表示 CloudFront 正在返回 HTTP 状态代码 >= 400 的响应这一事实。这不是“在”或“在”或“由 CloudFront 触发”或“由 CloudFront 生成”的错误. CloudFront 方面可以忽略——API-GW 或其背后的代理服务实际上是在抛出错误，因为它不喜欢 Content-Type。

标签： amazon-web-services aws-api-gateway amazon-kinesis amazon-kinesis-firehose http-status-code-415

【解决方案1】：

您从浏览器发出的请求中的内容类型是什么？如果请求中未指定 content-type 标头，则 API Gateway 默认采用“application/json”。

打开 chrome 并查看标题，我看到 cookie 以 text/html 的形式出现。

我不确定您是否将请求中的“Content-type”标头值设置为“text/html”。如果是，那就是问题所在。您将需要一个匹配的模板，或者您需要默认通过选择“当没有模板与请求 Content-Type 标头匹配时”。

【讨论】：