问题标签 [preflight]

我正在开发一个网络应用程序。它使用基本身份验证。它必须处理 OPTIONS 请求。这些是 Web 浏览器预检请求以及来自 WebDAV 客户端的功能支持请求。

据我了解，必须在不请求身份验证的情况下处理 OPTIONS 请求（即我的服务器不应以 401 Unauthorized 响应），它必须给出如下响应：

我的问题是：我是否应该始终对 OPTIONS 请求提供相同的响应，无论 URL 是什么，还是应该取决于 URL。

例如，如果找不到上面示例中的 file.ext，我应该回复“404 Not found”还是“200 OK”？

我创建 api 代理并选中“为您的 API 启用直接浏览器访问 - 允许通过 CORS 来自浏览器的直接请求”框。但我的 OPTIONS 请求仍然失败：

根据我对 CORS 飞行前选项请求的了解，客户端首先将 OPTIONS 请求发送到服务器，作为“安全”CORS 的保障。此请求应返回包含可用请求类型列表的响应。

我的问题：如何使 Apigee 正确响应 OPTIONS 请求并且不将 OPTIONS 请求传递给代理后面的我的 api？. 如果有帮助，我有 AngularJS javascript 应用程序尝试与我的 Apigee 端点通信。

Javascript 错误：

默认“添加 CORS”xml

默认代理端点 xml

默认目标端点 xml

我正在使用 jquery-fileupload 来允许用户将文件上传到外部服务（更具体地说是 Cloudinary）：

由于是外部目标，浏览器会发起 CORS 请求。但是，我注意到浏览器预先设置了 CORS 预检请求。 http://www.html5rocks.com/en/tutorials/cors/提供了关于何时触发预检请求以及何时不触发的很好的见解。据我所知，我的请求满足作为 CORS 简单请求的所有标准（请参阅“CORS 请求类型”部分）。

发送到外部服务的文件上传请求：

在文件上传请求之前发送到外部服务的附加预检请求：

有没有办法避免这个额外的预检请求？据我所知，文件上传请求是一个 CORS 简单请求，因为它是一个 HTTP POST，带有 Content-Type multipart/form-data 并且只有简单的请求 HTTP 标头。

我想摆脱额外的预检请求的原因是 Cloudinary 发送 HTTP 302/304 重定向作为对文件上传的响应。浏览器不遵循这些重定向。Chrome 失败并显示以下消息：

我是使用跨域资源共享并试图让我的 web 应用程序响应 CORS 请求的新手。我的 webapp 是在 Tomcat 7.0.42 上运行的 Spring 3.2 应用程序。

在我的 webapp 的 web.xml 中，我启用了 Tomcat CORS 过滤器：

我的客户端（使用 AngularJS 1.2.12 编写）正在尝试访问启用了基本身份验证的 REST 端点。当它发出 GET 请求时，Chrome 会首先对请求进行预检，但会收到来自服务器的 403 Forbidden 响应：

我不完全确定如何进行。 默认情况下，Tomcat 过滤器接受 OPTIONS 标头来访问资源。

我相信，问题在于我的资源（请求 URL）http://dev.mydomain.com/joeV2/users/listUsers被配置为只接受 GET 方法：

这是否意味着我必须使该方法/端点也接受 OPTIONS 方法？如果是这样，这是否意味着我必须明确地让每个 REST 端点接受 OPTIONS 方法？除了混乱的代码之外，我对它是如何工作的感到困惑。据我了解， OPTIONS 预检是让浏览器验证浏览器是否应该有权访问指定的资源。我理解这意味着在预检期间甚至不应该调用我的控制器方法。因此，将 OPTIONS 指定为可接受的方法会适得其反。

Tomcat 是否应该直接响应 OPTIONS 请求而不访问我的代码？如果是这样，我的配置中是否缺少某些内容？

我正在阅读有关 CORS 请求的规范，我发现这是关于预检请求的：

这些是使用除 GET 之外的 HTTP 请求方法对非同源 URL 的请求，首先需要使用预检结果缓存条目或预检请求进行授权。

我曾认为预检请求的目的是在发出请求之前检查是否允许请求，以防它（非法）更改服务器状态。

但是 HEAD 和 OPTIONS 不会修改服务器状态。我必须误解飞行前检查的原因。

对 HEAD 和 OPTIONS 而不是 GET 进行预检的目的（也称为原因、动机或基本原理）是什么？GET有什么特别之处？

AngularJS 使用 REST 对服务器端进行身份验证，并获取 JSESSIONID cookie。在下一步中，我将尝试使用 REST 从服务器端获取一些 JSON 数据以及在上一步中获得的会话 cookie。这是客户端代码：

上面的代码工作正常：

当我在上面的 POST 请求正文中发送一些数据时，问题就开始了。

上面的代码在 prelight 请求中失败：

看起来服务器启动了一个新会话，因为会话 cookie 由于某种原因没有发送。无论如何，我觉得我错过了一些非常简单的东西，一些标题或类似的东西......任何想法都值得赞赏。提前致谢。

我有一个从服务器上的 IIS 运行的简单 GWT 应用程序。我正在尝试测试对在同一台服务器上运行的 tomcat 的 HTTP 请求。但是，由于两个应用程序服务器都在不同的端口上运行，我的浏览器（chrome 和 firefox）将请求视为 CORS 请求。

为了使 tomcat 能够接受 CORS 请求，我将其更新为 Tomcat 7.0.52 并在全局 web.xml 配置中启用了 CORS 过滤器。我测试了这个简单的设置，它似乎工作。这是 GWT 中的代码：

这是与之关联的 CORS 过滤器：

通过这个设置，我得到了来自 tomcat 的 200 OK 响应。因此可以安全地假设 CORS 过滤器正在工作。为了支持这一点，我做了一个提琴手跟踪，一切看起来都很好。

现在，由于我想访问 tomcat(solr) 的应用程序之一，我需要对我的 CORS 请求进行基本身份验证。这带来了预检请求。由于我设置了我的 CORS 过滤器以启用凭证使用，因此我不需要对其进行任何更改。所以，我对我的代码进行了以下更改

现在，当我尝试使用此代码时，它会进入onResponseReceived代码块并给出一个带有“0”值的警报框。当我进行提琴手跟踪时，我得到了这个：

由于我将自定义标头添加到请求中，因此浏览器发送预检请求是有意义的。但我不明白为什么尽管将授权标头添加到其 CORS 过滤器配置中，但 tomcat 仍以 401 代码响应。

我将不胜感激任何帮助或回应

编辑：我注意到的另一件事 - 如果我的 URL 只是“bavarians:8080/solr/”;，tomcat 成功授权预检请求，并且立即下一个请求被处理为具有 200 OK 响应的普通 GET 请求。但是如果我输入函数名称并使用 URL 进行查询，我会再次得到 401。从浏览器访问上述 URL 需要基本身份验证。直到CORSFilter某个时候才起作用

我们有一个 PDF 文档处理系统，在 AppleScript 中实现（我们使用 osascript 从 shell 调用脚本）。在某些脚本中，我们从 Applescript 调用 Acrobat Preflight Droplets。

这通常可以毫无问题地工作。但是，在某些情况下，处理的文档很大或/和复杂。在编写报告并将文档移动到“成功”或“失败”文件夹之前，液滴将控制权返回给脚本。结果是该过程继续进行，但如果没有移动的文件，它最终会失败。

到目前为止，解决方法是在这些 droplet 调用之后添加延迟。这确实有帮助，但对于小型文档来说这是浪费时间，而且总会有一个足够大和复杂的文档来花费比延迟更长的时间。

我们还发现，完成编写报告和移动文档所需的时间取决于系统的速度（必须预料到......）。

解决方法是根据文档大小、其页数和与机器相关的参数来计算延迟。文档大小和页数没什么大不了的；它们可以在 Applescript 中检索。

问题是机器相关参数，可以通过实验确定。但是如何使该参数对所有需要它的脚本可用？

将它合并到脚本中不是一种选择，因为我们安装了许多系统，如果我们这样做，我们最终会陷入维护的噩梦。在初始系统调用中将它作为参数传递也是不可能的，因为调用很多，并且会再次导致维护噩梦。

那么，有没有办法建立一个可以存储机器参数的地方，并且可以从任何 Applescript 轻松调用，无论它本身是如何调用的。

非常感谢您的建议。

我开发了一个PhoneGap 应用程序，现在它正在转变为一个移动网站。除了一个小故障外，一切都很顺利。我通过 POST 请求使用某个第三方 API，它在应用程序中运行良好，但在移动网站版本中失败。

仔细一看，AngularJS（我猜实际上是浏览器）似乎首先发送了一个 OPTIONS 请求。我今天学到了很多关于 CORS 的知识，但我似乎无法弄清楚如何完全禁用它。我无权访问该 API（因此无法在该端进行更改），但他们已将我正在处理的域添加到他们的 Access-Control-Allow-Origin 标头中。

这是我正在谈论的代码：

如何防止浏览器（或 AngularJS）发送该 OPTIONS 请求而直接跳到实际的 POST 请求？我正在使用 AngularJS 1.2.0。

提前致谢。

所以我在 Go 中编写了这个 RESTful 后端，它将被跨站点 HTTP 请求调用，即来自另一个站点提供的内容（实际上，只是另一个端口，但同源策略生效，所以我们在这里） .

在这种情况下，用户代理将在某些情况下发送预检 OPTIONS 请求以检查实际请求是否可以安全发送。

我的问题是如何在 Go 上下文中最好地处理和充分响应这些预检请求。我构想的方式感觉不是很优雅，我想知道是否还有其他我没有想到的方法。

使用标准net/http包，我可以在处理函数 func 中检查请求方法，可能是这样的：

我还可以使用Gorilla 的 mux包，并为每个相关的 URL 路径注册一个预检“OPTIONS”处理程序。

也许对这个问题的回答很简单：是的，这些是您的基本选择。但我认为可能有一些我不知道的最佳实践。