Chrome浏览器如何决定何时发送选项？ [英] How does the Chrome browser decide when to send OPTIONS?

问题描述

我有一个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.com& 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.org/TR/cors/#cross-origin-request-with-preflightrel =noreferrer>带预检的交叉来源请求算法。

注意：使用简单方法的交叉源请求作者请求标题，不是 simple 将有一个预检请求，以确保资源可以处理这些标题。 （与使用非简单方法的方法的请求类似。）

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

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

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

为了使请求成功，你的服务器应该处理OPTIONS请求并回应：

pre $ Access-Control-Allow-Origin：https://example.com
访问控制-Allow-Headers：authorization


要了解更多关于CORS的信息，请参阅 https://developer.mozilla.org/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 http://localhost:3048/Token HTTP/1.1
Host: localhost:3048
Connection: keep-alive
Content-Length: 78
Accept: application/json, text/plain, */*
Origin: http://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: http://localhost:2757/Auth/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

grant_type=password&username=xxx%40live.com&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 http://localhost:3048/Token HTTP/1.1
Host: localhost:3048
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://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: http://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: https://example.com
Access-Control-Allow-Headers: authorization

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

这篇关于Chrome浏览器如何决定何时发送选项？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！