我的客户端Web应用程序是使用Angular编写的，而服务器端是AWS API网关。
我遇到了错误：
Access to XMLHttpRequest at <my destiniation> from origin <my origin> has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
<my destination>和<my origin>不是同一域。
问题是我确实有CORS设置来支持此功能。我的设置使用一个预检OPTIONS请求，然后是一个PUT请求（PUT是403失败的原因，控制台显示了CORS错误）。实际上，来自OPTIONS请求的响应确实包含access-control-allow-origin: *，最奇怪的是，只有当我的一个（或多个）URL参数参数中包含％23时，我的PUT请求才会失败（例如， URL编码＃符号的结果）。
有人知道为什么URL参数中的特殊字符会触发CORS错误，而没有特殊字符的完全相同的请求通过CORS却没有任何问题？我可能会缺少什么？
答案 0 :(得分：0)
感谢sideshowbarker的帮助，我得以解决此问题。事实证明，CORS错误实际上是一个红色鲱鱼。
更深入地了解后，我了解到AWS签名不匹配（但仅当包含特殊字符时才匹配），并且我发现我需要对参数进行双重编码才能正确计算签名。我在可能包含特殊字符的每个参数上使用decodeURIComponent()进行了此操作，然后在生成的整个URL上使用了decodeURI()（有效地对有问题的参数进行了双重编码）。现在签名通过，请求成功。
此问题/解决方案可能是我的客户端应用程序（在Angular中）使用AWS签名的方式所独有的，但对于遇到类似错误的其他人来说，它可能会派上用场。
答案 1 :(得分：0)
在对同一问题进行数小时的检查后，正如 jrel 评论的那样，结果证明这是一个红鲱鱼。 在我的特殊情况下，问题出在我们的 nginx 服务器和机器上安装的 modsecurity + Owasp CRS 规则中。每次在 URL 中检测到查询字符串时，请求都会由于可能的 XSS 攻击而被阻止。