使用API网关提供不正确的CORS响应的Lambda
问题描述：
我有一个Lambda部署在AWS内的API网关后面，并启用了API缓存。使用API网关提供不正确的CORS响应的Lambda
已经使用标准启用CORS选项，这已在OPTIONS方法创建的报头映射Access-Control-Allow-Origin: *配置。
但是，当调用API来执行Lambda上的方法时，响应中的Access-Control-Allow-Origin标头将被设置为请求中的origin标头。
这是由于我选择了启用API缓存导致了一个问题。
看起来这是导致响应被缓存与域特定的Access-Control-Allow-Origin响应。即不是Access-Control-Allow-Origin: *，而是Access-Control-Allow-Origin: {whatever the origin header of the request was
这导致客户端的CORS故障。
我找不到有关此行为的任何文档以及为何发生这种情况？
答
CORS响应正在Lambda中生成，而不是API网关。
基于Python的Lambda使用的flask-cors库设置不正确。
作为每文档：
send_wildcard（布尔） - 如果为True，以及起源参数是*，一个 通配符访问控制允许来源头中发送，而不是 请求的来源头。
默认值：在代码
CORS(app)假
因此已改为
CORS(app, send_wildcard=True)
，我知道得到我想要的行为，这是对Access-Control-Allow-Origin头回应为*
如果您可以导致'Origin'的'Vary'响应头也被添加到响应中，那么当'Origin'请求头的值不同于请求的'Origin'值时，它被高速缓存from，这应该具有导致缓存被跳过的效果，并且会产生新的网络请求。 请参阅[HTTP规范的相关部分]（https://tools.ietf.org/html/rfc7231#section-7.1.4）和[关于'Vary'的MDN文章]（https：// developer。 mozilla.org/en-US/docs/Web/HTTP/Headers/Vary）。 – sideshowbarker
当Lambda与API网关一起使用时，我不认为这是可能的@sideshowbarker。在AWS中设置响应标头的功能已被删除。 –