Chrome 浏览器如何决定何时发送 OPTIONS?

本文介绍了Chrome 浏览器如何决定何时发送 OPTIONS?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个 AngularJS WebAPI 应用程序.

I have an AngularJS WebAPI application.

据我所知，OPTIONS 请求是由浏览器自动构建的.

As far as I can understand the OPTIONS request is constructed automatically by the browser.

POST localhost:3048/Token HTTP/1.1 Host: localhost:3048 Connection: keep-alive Content-Length: 78 Accept: application/json, text/plain, */* Origin: localhost:2757 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 Content-Type: application/x-www-form-urlencoded Referer: localhost:2757/Auth/login Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.8 grant_type=password&username=xxx%40live&password=xxx

回复:

HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Length: 971 Content-Type: application/json;charset=UTF-8 Expires: -1 Server: Microsoft-IIS/8.0 Access-Control-Allow-Origin: * Set-Cookie: .AspNet.Cookies=CpvxrR1gPFNs0vP8GAmcUt0EiKuEzLS1stLl-70O93wsipJkLUZuNdwC8tZc5M0o1ifoCjvnRXKjEBk3nLRbFlbldJLydW2BWonr5JmBjRjXZyKtcc29ggAVhZlc2E-3gGDlyoZLAa5Et8zrAokl8vsSoXmHnsjrxZw0VecB_Ry98Ln84UuKdeHlwSBnfaKKJfsN-u3Rsm6MoEfBO5aAFEekhVBWytrYDx5ks-iVok3TjJgaPc5ex53kp7qrtH3izbjT7HtnrsYYtcfPtmsxbCXBkX4ssCBthIl-NsN2wObyoEqHMpFEf1E9sB86PJhTCySEJoeUJ5u3juTnPlQnHsk1UTcO0tDb39g-_BD-I4FWS5GMwxLNtmut3Ynjir0GndwqsvpEsLls1Y4Pq7UuVCTn7DMO4seb64Sy8oEYkKZYk9tU4tsJuGD2CAIhdSc-lAmTAA78J5NOx23klkiuSe_SSiiZo5uRpas_1CFHjhi1c8ItEMpgeTsvgTkxafq5EOIWKPRxEHbCE8Dv106k5GlKK5BaH6z7ESg5BHPBvY8; path=/; HttpOnly X-SourceFiles: =?UTF-8?B?QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4=?= X-Powered-By: ASP.NET Date: Tue, 13 Jan 2015 04:54:55 GMT {"access_token":"TkJ2trqT ....

现在登录

我注销，这只不过是删除令牌并重新登录.发生了一些不同的事情.之前它没有发送 OPTIONS 但现在它发送了.之前的请求/响应是否会影响浏览器在我第二次登录时采取不同的行为?

I log out which is nothing more than removing the token and log in again. Something happens that is different. Before it did not send the OPTIONS but now it does. Is there something resulting from a previous request/response that would influence the browser to act different the second time I log in?

OPTIONS localhost:3048/Token HTTP/1.1 Host: localhost:3048 Connection: keep-alive Access-Control-Request-Method: POST Origin: localhost:2757 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 Access-Control-Request-Headers: accept, authorization, content-type Accept: */* Referer: localhost:2757/Auth/login Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8

回复:

HTTP/1.1 400 Bad Request Cache-Control: no-cache Pragma: no-cache Content-Length: 34 Content-Type: application/json;charset=UTF-8 Expires: -1 Server: Microsoft-IIS/8.0 X-SourceFiles: =?UTF-8?B?QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4=?= X-Powered-By: ASP.NET Date: Tue, 13 Jan 2015 04:56:32 GMT {"error":"unsupported_grant_type"}

如果我重置浏览器并重新加载页面，那么它会回到第一次不发送 OPTIONS 之前的状态，我可以登录.

If I do a browser reset and reload of the page then it goes back to like before where it does not send OPTIONS the first time and I am able to log in.

可能我需要更改服务器上的某些内容，以便它处理选项.

Probably I need to change something on the server so it handles options.

但是为什么我的浏览器(Chrome)第一次没有发送选项?

BUT why does my browser (Chrome) not send OPTIONS the first time?

推荐答案

Chrome(或任何其他浏览器)是否发送 OPTIONS 请求完全由 CORS 规范:

Whether the Chrome (or any other browser) sends an OPTIONS request is exactly specified by the CORS specfication:

当跨域请求算法被调用时，这些必须遵循的步骤:...2.如果满足以下条件，则按照简单跨域请求 算法:

When the cross-origin request algorithm is invoked, these steps must be followed: ... 2. If the following conditions are true, follow the simple cross-origin request algorithm:

• 请求方法是简单方法 和 强制预检标志 未设置.

每个作者请求标头都是一个简单标题 或 作者请求标头 为空.

Each of the author request headers is a simple header or author request headers is empty.

3.否则，按照cross-origin使用预检算法请求.注意:使用简单的方法的跨源请求a> 带有 作者请求标头 不是 simple 将有一个 预检请求 以确保资源可以处理这些标头.(类似于使用不是简单方法的方法的请求.)

3.Otherwise, follow the cross-origin request with preflight algorithm. Note: Cross-origin requests using a method that is simple with author request headers that are not simple will have a preflight request to ensure that the resource can handle those headers. (Similarly to requests using a method that is not a simple method.)

您的 OPTIONS 请求包含以下请求标头:

Your OPTIONS request contains the following request header:

Access-Control-Request-Headers: accept, authorization, content-type

这意味着您的 Angular 应用插入了非simple Authorization 请求标头，可能作为身份验证方案的一部分.非简单的作者请求标头"会触发 OPTIONS 请求，如您在上面的引用中所见.

This means that your Angular app has inserted the non-simple Authorization request header, probably as a part of an authentication scheme. Non-simple "author request headers" trigger the OPTIONS request, as you can see in the above quote.

为了让请求成功，您的服务器应该处理 OPTIONS 请求并响应:

To allow the request to succeed, your server should handle OPTIONS request and respond with:

Access-Control-Allow-Origin: example Access-Control-Allow-Headers: authorization

要了解有关 CORS 的更多信息，请参阅 developer.mozilla/en-US/docs/Web/HTTP/Access_control_CORS.

To learn more about CORS, see developer.mozilla/en-US/docs/Web/HTTP/Access_control_CORS.