Chrome浏览器如何决定何时发送选项？

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

我有一个AngularJS WebAPI应用程序。

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

POST http：// localhost：3048 / Token HTTP / 1.1 Host：localhost：3048 Connection：keep-alive Content-Length：78 接受：application / json，text / plain，* / * Origin：http：// localhost：2757 User-代理：Mozilla / 5.0（Windows NT 6.1; WOW64）AppleWebKit / 537.36（KHTML，如Gecko）Chrome / 39.0.2171.95 Safari / 537.36 内容类型：application / x-www-form-urlencoded Referer：http：// 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-长度：971 内容类型：application / json; charset = UTF-8 过期时间：-1 服务器：Microsoft-IIS / 8.0 Access-Control-Allow-Origin ：* Set-Cookie：.AspNet.Cookies = CpvxrR1gPFNs0vP8GAmcUt0EiKuEzLS1stLl-70O93wsipJkLUZuNdwC8tZc5M0o1 ifoCjvnRXKjEBk3nLRbFlbldJLydW2BWonr5JmBjRjXZyKtcc29ggAVhZlc2E-3gGDlyoZLAa5Et8zrAokl8vsSoXmHnsjrxZw0VecB_Ry98Ln84UuKdeHlwSBnfaKKJfsN-u3Rsm6MoEfBO5aAFEekhVBWytrYDx5ks-iVok3TjJgaPc5ex53kp7qrtH3izbjT7HtnrsYYtcfPtmsxbCXBkX4ssCBthIl-NsN2wObyoEqHMpFEf1E9sB86PJhTCySEJoeUJ5u3juTnPlQnHsk1UTcO0tDb39g-_BD-I4FWS5GMwxLNtmut3Ynjir0GndwqsvpEsLls1Y4Pq7UuVCTn7DMO4seb64Sy8oEYkKZYk9tU4tsJuGD2CAIhdSc-lAmTAA78J5NOx23klkiuSe_SSiiZo5uRpas_1CFHjhi1c8ItEMpgeTsvgTkxafq5EOIWKPRxEHbCE8Dv106k5GlKK5BaH6z7ESg5BHPBvY8;路径= /; HttpOnly X-SourceFiles：=？UTF-8？B？QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4 =？= X-Powered-By：ASP.NET 日期：2015年1月13日星期二04:54:55 GMT {access_token：TkJ2trqT ....

现在登录

我注销掉的只是删除令牌并重新登录。发生的事情不同。在它没有发送OPTIONS但现在它。以前的请求/响应是否会影响浏览器在第二次登录时采取不同的行为？

选项http：// localhost：3048 / Token HTTP / 1.1 主机：localhost：3048 连接：keep-alive 访问控制请求方法：POST 原产地： http：// localhost：2757 User-Agent：Mozilla / 5.0（Windows NT 6.1; WOW64）AppleWebKit / 537.36（KHTML，如Gecko）Chrome / 39.0.2171.95 Safari / 537.36 Access-Control- Request-Headers：接受，授权，内容类型接受：* / * 引用者：h ttp：// 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 服务器：Microsoft-IIS / 8.0 X-SourceFiles：=？UTF-8？B？QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4 =？= X-Powered-by-ASP.NET 日期：2015年1月13日星期二04:56:32 GMT {error：unsupported_grant_type}

如果我执行浏览器重置并重新加载页面，则会返回到之前不会发送OPTIONS并且能够登录的位置。

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

但为什么我的浏览器（Chrome）第一次没有发送OPTIONS？

解决方案 div>

Chrome（或任何其他浏览器）是否发送OPTIONS请求由 CORS specfication ：

当 cross-origin request 算法被调用，这些步骤必须遵循： ... 2.如果以下条件属实，请遵循简单的跨国请求算法：

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

author request headers 是简单标题或作者请求标题为空。 /www.w3/TR/cors/#cross-origin-request-with-preflightrel =noreferrer>带预检的交叉来源请求算法。 注意：使用简单方法的交叉源请求作者请求标题，不是 simple 将有一个预检请求，以确保资源可以处理这些标题。 （与使用非简单方法的方法的请求类似。）

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

访问控制请求标题：接受，授权，内容类型

这意味着您的Angular应用程序已经插入了非简单 授权请求标头，可能作为验证方案的一部分。非简单的作者请求标题会触发OPTIONS请求，正如你在上面的引用中看到的那样。

为了使请求成功，你的服务器应该处理OPTIONS请求并回应： pre $ Access-Control-Allow-Origin：example 访问控制-Allow-Headers：authorization

要了解更多关于CORS的信息，请参阅 developer.mozilla/zh-CN/docs/Web/HTTP/Access_control_CORS 。

I have an AngularJS WebAPI application.

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

Response:

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 ....

Now logged in

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

Response:

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"}

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.

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

解决方案

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

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:

• The request method is a simple method and the force preflight flag is unset.

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

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.)

Your OPTIONS request contains the following request header:

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

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.

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

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