编辑:看起来这篇文章没什么大不了的,因为 OPTIONS 预检是在去年秋天晚些时候推出的;我的问题更多的是用户错误。有关更多详细信息,请参阅评论(为了文档,我将全部保留在这里)。--jlm
Youtube API 不支持 OPTIONS 请求方法是一个已知问题,因此任何尝试进行跨域预检的 Web 应用程序都会失败,即使(与 Youtube API 一样)实际的 CORS 请求会成功. 由于我们本周再次面临这个问题,因此我们提出了三种解决方法;但是,每个都有自己的优点和缺点。
可能的解决方法 #1:忘记预检,只需发出简单的跨域请求。
好处——A)它有效。B)这是执行大多数 GET 或 POST 请求时所需的全部规范。
缺点-- A) 规范规定,任何 PATCH、PUT 或 DELETE 请求,以及使用除表单数据、url-encoded 或 text/plain 以外的内容类型的 POST 请求都需要进行预检。因此,虽然它会起作用,但它会违反规范(如果可能,我们希望避免这种情况)。B) 设置自定义标头时也需要预检;因此,例如,当我在 1.0 分支中使用 AngularJS 的 $http 方法时,它会设置一个自定义标头,从而触发对 GET 请求的预检。当然,在这种情况下,我可以编写自己的 $http 服务或移至 1.1 分支(因为问题实际上出在 Angluar 端)。
可能的解决方法 #2:使用 JSON-P
好处——A)它也有效(在某些情况下,无论如何)。B) 设置起来相当简单。
缺点-- A) 一种较旧的技术,尚不清楚 Youtube API 是否会继续支持 JSONP。B) 需要回调。C) 仅限于 GET 请求。
可能的解决方法 #3:在同一域上设置服务器端代理,使用它与 Youtube API 进行通信。
好处- A) 完全避免了 CORS 请求,因为客户端在同一个源上工作,而服务器端代理不需要预检任何东西。
缺点- A) 设置起来可能会变得复杂,尤其是在尝试使用凭据时(通过代理的 oAuth2 可能是相当的野兽)。
所以这篇文章有一个实际的问题(或几个,实际上)
- 您对上述任何或所有解决方法有什么看法(无论好坏)?
- 有没有人实施其他解决方案?
- 是否有任何关于 Youtube 服务器是否/何时可能支持 OPTIONS 方法的信息?
欢迎任何和所有评论 - 如果这不是解决此类问题的最佳论坛,我提前道歉(尽管我希望通过将它放在 Stack Overflow 上,它会对面临相同问题的其他人有用问题)