问题标签 [http-options-method]

我正在使用 Spring Data REST 构建一个 RESTful API。到目前为止，我的这个 RESTful 服务的 HTML GUI 是由同一个 Tomcat 提供的，而且我对跨域请求没有任何问题。

现在我想从不同的服务器提供静态文件。这意味着 API 在另一个域/端口上。浏览器将发送 OPTIONS 请求以从服务器获取 Access-Control 标头。不幸的是，Spring Data REST 不处理那些 OPTIONS 请求，甚至返回 HTTP 500。

我尝试创建一个处理所有 OPTIONS 请求的自定义控制器

这适用于 OPTIONS，但随后所有其他请求（如 GET）都停止工作。

OPTIONS 请求通过 dispatchOptionsRequest 调度程序 servlet 参数打开。

对 OPTIONS 请求的响应有什么问题吗？

我在 Chrome 中得到了对 OPTIONS 请求的完全相同的响应，它工作得非常好，而 Firefox 在响应后不会继续使用 AJAX。

使用 jQuery 文件上传，我将文件上传到第三方服务器，该服务器需要对所有传入请求进行令牌身份验证。在上传之前，浏览器会发送一个 OPTIONS 请求来检查跨域授权。该请求失败并返回 401，因为它不包含令牌。如何向该请求添加“授权：令牌”标头？

在 curl 这工作： curl -X OPTIONS https://api.example.com -H 'Authorization: Token <TOKEN>'

我尝试了以下三个选项，但没有运气：

我试图找出我的客户端和 REST API 之间的通信问题。我可以确定问题，但我不确定 OPTION 请求的答案中究竟缺少什么。我的应用程序正在创建一个 HTTP POST，它由浏览器使用 HTTP-OPTION 预检。该选项要求批准自定义内容类型。服务器回答 OPTION 后，不会发送 POST。

答案如下所示：

我是否正确，答案中应该有一行批准请求的内容类型？像这样：

我正在开发一个使用嵌入式 Jetty 的项目（不幸的是，我只是“继承”了项目的服务器端，并且对 Jetty 的使用及其配置不是很熟悉）。

突然出现了一个奇怪的案例-我会尽力描述：

基于 Web 的 UI（使用 AngularJS，来自不同的域，因此使用了 CORS）发送 POST 请求以更改服务器上某些内容的状态。这在过去的某个时候有效（它最后一次使用可能是在一个月左右之前）。

昨天这停止了工作。检查 REST 调用，我看到首先发出了一个 OPTIONS 请求。POST 的内容类型是 application/json，所以根据我的阅读，这是正确的。我不确定为什么之前没有发送它 - 公司最近更新了 Chrome 版本，而旧版本没有发送预检请求，但这只是猜测。无论如何，我认为这是我的应用程序中用于为 CORS 配置 Jetty 的相关代码：

POST 请求一切正常。我可以通过使用 --disable-web-security 标志启动 Chrome 来验证这一点。没有发送任何 OPTIONS 请求，并且 POST 正常工作。

我的想法是，因为它适用于 POST，所以它不是授权或安全问题 - 只是 Jetty 没有正确配置来处理预检请求（它只返回 401）。

我找不到太多关于嵌入式 Jetty 的文档，以及哪些 CrossOriginFilter 常量在调用 setInitParameter 时用作属性键（此外，由于该方法调用的第二个参数是一个字符串，我真的不知道如何格式化值）。

我应该在 CrossOriginFilter 上设置哪些参数来处理 OPTIONS 请求？如果我在上面说了什么错误或做出了任何错误的假设，请纠正我！我在这方面的经验非常有限。

I'm trying to implement proper CORS logic in my service. From looking at all the available documentation, it's not clear to me whether, in the case of a cross-origin OPTIONS request, the client would send (1) a pre-flight OPTIONS request, and if allowed by the pre-flight response, (2) a "regular" (non-pre-flight) OPTIONS request.

In other words, in my server, when I get a pre-flight OPTIONS request, should I execute both the CORS logic and the normal OPTIONS request processing logic at the same time, populating the normal OPTIONS response headers as well as the the Access-Control-* response headers?

Or should I just do the CORS logic for the pre-flight request, and expect a follow-up OPTIONS request if the OPTIONS method is allowed from the origin?

[extra credit for pointing to an authoritative reference]

I have a set of REST services that all follow same URL/verb pattern.
A few of those do not implement certain inessential combinations of URL/verb.

Since the application using those services does not know in advance which operations are implemented, it has to discover unimplemented ones dynamically.

I see two approaches:

1. Sending 501 Not Implemented when the operation is requested
2. Setting up OPTIONS support so that services can declare what they support

First approach seems better at the moment, since it is easier to implement, and requires one less request for the positive case (considering that OPTIONS are not cacheable).

Is there anything technically wrong with that approach?

我的问题：
由于 OPTIONS 请求失败，浏览器不允许发送请求。

使用 javascript 发送的数据如下所示：

这是请求后从 chrome 控制台看到的样子：

注意
当我尝试从提琴手发帖时，请求成功成功。
但是，如果我试图从提琴手发出选项请求，它会像 chrome 一样失败。

有任何想法吗？

介绍

我已阅读以下内容：

超文本传输​​协议 (HTTP) 是网络的生命。每次传输文档或发出 AJAX 请求时都会使用它。但令人惊讶的是，HTTP 在一些 Web 开发人员中相对未知。

HTTP 动词构成了我们“统一接口”约束的主要部分，并为我们提供了与基于名词的资源对应的动作。主要或最常用的 HTTP 动词（或正确称呼的方法）是 POST、GET、PUT和DELETE。

嗯？

好吧，我们到了我忘记了事情的地步。

PUT并且DELETE，他们说。在我看过的任何 PHP 代码中，我只听说过POST并且GET从未见过类似$_PUT或$_DELETE经过的东西。

我的问题

这些方法 (PUT) 和 (DELETE) 的用途是什么，如果可以在 PHP 中使用它们，我将如何处理。

注意：我知道这不是一个真正的问题，但如果我看到一个，我总是会抓住一个学习机会，如果可能的话，我非常想学习在 PHP 中使用这些方法。

jQuery 应该发送一个 HTTP OPTION 请求来启动 pre-flight CORS，但它总是发送一个 HTTP POST。由于它是一个 POST 浏览器没有获得 Access-Control-Allow-Origin 或 Access-Control-Allow-Method 并且浏览器没有选择，而是 404 响应。