API 当 CORS OPTIONS 请求成功完成时，网关间歇性 returns "No 'Access-Control-Allow-Origin' header is present..."
API Gateway intermittently returns "No 'Access-Control-Allow-Origin' header is present..." when the CORS OPTIONS request completes successfully
我完全不知道现在发生了什么。几个小时以来，我一直在阅读有关 API Gateway CORS 的帖子，它们都归结为相同的基本内容。您没有在 API 上正确启用 OPTIONS 请求；我 99% 确定我在这一点上做对了。
我正在使用通过 API 网关映射的 Amazon.Lambda.AspNetCoreServer 库提供的 Lambda 托管的 Kestrel API。我目前将它托管在一个私有子网中，它可以通过 NAT 网关提供互联网访问，所有这些都已经通过在私有子网中启动的 EC2 实例进行了测试。我有 API 网关在 api.example.com 上工作，而实际网站通过 S3 静态网站托管在 example.com。
CORS 已在启动 class 中的 Kestrel Web API 和 API 网关映射中启用，两者都允许所有路径。我一直在努力决定是否在 API 网关层上启用 CORS，因为我已经阅读了 API 网关代理集成，您可以简单地将所有 CORS 验证卸载到Lambda 层，这比在 2 个不同的地方复制 CORS 验证更有意义（API 网关和 Web API）。
从我的网络客户端，我可以在大多数情况下毫无问题地针对 API 发出请求。看来，当我给它足够的时间时，后续的请求注定会失败。当用户登陆页面时，我触发了对 Lambda 的 "activation" 调用，以防止任何后续操作发生 long-load 次。这应该确保用户使用热 lambda 或冷冻 lambda 而不是冷 lambda。几分钟后问题似乎出现了，之前的 lambda 实例可能不再存在。
如果我加载页面，lambda 应该被激活。如果我给它一点时间，然后尝试提交联系信息，我通常会收到请求失败。开发者控制台提示报错"No 'Access-Control-Allow-Origin' header is present..."；但是，在特定时间我可以看到选项请求通过，但失败的响应不包含 access-control-allow-origin header.
我完全不知所措，如果其他人可以帮助解释我所看到的不一致之处，那将不胜感激。如果 Lambda 停止在我的 C# 应用程序中的 CloudWatch 中引发 C 语言错误，这将容易一百万倍。我对 Lambda 感到非常沮丧，并开始考虑使用替代托管方法。
虽然我的回答相对较快，但 post 是经过几天研究后的最后努力。事实证明，该问题与 CORS 并不真正相关，但与 Startup.cs class 中异步上下文的使用有关。
这个问题所涉及的失败专门针对异步 POST 方法。这个应用程序还处于早期阶段，所以我可以使用的异步方法并不多。我原以为这是更高级别的失败；然而，这实际上是控制器级别的异步上下文失败。
我曾尝试在 Startup.cs class 中使用异步方法来协助初始化 Singleton 服务。此启动 class 中的 Task.WaitAll 用法破坏了整个应用程序的异步上下文。事实证明，我必须等待异步调用的任何尝试都会导致失败。最后，所有这些都源于我在启动时使用异步方法class。
一旦我删除了我的异步启动方法，我就能够毫无问题地点击我的 API。在 CORS 方法填充期间间歇性发生的失败是由于失败的异步上下文；但是，由于它是在请求 OPTIONS 方法时发生的，因此将失败归因于 CORS。
今日课程：如果您希望使用包 Amazon.Lambda.AspNetCoreServer 在 Lambda 微服务中实例化 Kestrel API，您最好不要使用 ASYNC 或 TASK IN Startup.cs
我完全不知道现在发生了什么。几个小时以来，我一直在阅读有关 API Gateway CORS 的帖子，它们都归结为相同的基本内容。您没有在 API 上正确启用 OPTIONS 请求；我 99% 确定我在这一点上做对了。
我正在使用通过 API 网关映射的 Amazon.Lambda.AspNetCoreServer 库提供的 Lambda 托管的 Kestrel API。我目前将它托管在一个私有子网中，它可以通过 NAT 网关提供互联网访问，所有这些都已经通过在私有子网中启动的 EC2 实例进行了测试。我有 API 网关在 api.example.com 上工作，而实际网站通过 S3 静态网站托管在 example.com。
CORS 已在启动 class 中的 Kestrel Web API 和 API 网关映射中启用，两者都允许所有路径。我一直在努力决定是否在 API 网关层上启用 CORS，因为我已经阅读了 API 网关代理集成，您可以简单地将所有 CORS 验证卸载到Lambda 层，这比在 2 个不同的地方复制 CORS 验证更有意义（API 网关和 Web API）。
从我的网络客户端，我可以在大多数情况下毫无问题地针对 API 发出请求。看来，当我给它足够的时间时，后续的请求注定会失败。当用户登陆页面时，我触发了对 Lambda 的 "activation" 调用，以防止任何后续操作发生 long-load 次。这应该确保用户使用热 lambda 或冷冻 lambda 而不是冷 lambda。几分钟后问题似乎出现了，之前的 lambda 实例可能不再存在。
如果我加载页面，lambda 应该被激活。如果我给它一点时间，然后尝试提交联系信息，我通常会收到请求失败。开发者控制台提示报错"No 'Access-Control-Allow-Origin' header is present..."；但是，在特定时间我可以看到选项请求通过，但失败的响应不包含 access-control-allow-origin header.
我完全不知所措，如果其他人可以帮助解释我所看到的不一致之处，那将不胜感激。如果 Lambda 停止在我的 C# 应用程序中的 CloudWatch 中引发 C 语言错误，这将容易一百万倍。我对 Lambda 感到非常沮丧，并开始考虑使用替代托管方法。
虽然我的回答相对较快，但 post 是经过几天研究后的最后努力。事实证明，该问题与 CORS 并不真正相关，但与 Startup.cs class 中异步上下文的使用有关。
这个问题所涉及的失败专门针对异步 POST 方法。这个应用程序还处于早期阶段，所以我可以使用的异步方法并不多。我原以为这是更高级别的失败；然而，这实际上是控制器级别的异步上下文失败。
我曾尝试在 Startup.cs class 中使用异步方法来协助初始化 Singleton 服务。此启动 class 中的 Task.WaitAll 用法破坏了整个应用程序的异步上下文。事实证明，我必须等待异步调用的任何尝试都会导致失败。最后，所有这些都源于我在启动时使用异步方法class。
一旦我删除了我的异步启动方法，我就能够毫无问题地点击我的 API。在 CORS 方法填充期间间歇性发生的失败是由于失败的异步上下文；但是，由于它是在请求 OPTIONS 方法时发生的，因此将失败归因于 CORS。
今日课程：如果您希望使用包 Amazon.Lambda.AspNetCoreServer 在 Lambda 微服务中实例化 Kestrel API，您最好不要使用 ASYNC 或 TASK IN Startup.cs