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

时间:2015-01-13 05:03:39

标签: google-chrome http asp.net-web-api http-headers cors

我有一个AngularJS WebAPI应用程序。

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

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

响应:

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之前,但现在确实如此。以前的请求/响应是否会导致浏览器在第二次登录时影响不同?

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

响应:

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并且我能够登录。

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

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

3 个答案:

答案 0 :(得分:17)

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

  

调用cross-origin request算法时,必须遵循以下步骤:
  ...
  2.如果满足以下条件,请遵循simple cross-origin request算法:

           

3。否则,请遵循cross-origin request with preflight算法    注意:使用simple author request headerssimplepreflight request的方法的跨源请求将具有simple method以确保资源可以处理这些标题。 (与使用非simple方法的请求类似。)

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

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

这意味着您的Angular应用已插入非https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS Authorization请求标头,可能是身份验证方案的一部分。非简单的“作者请求标题”会触发OPTIONS请求,如上面的引用所示。

为了让请求成功,您的服务器应该处理OPTIONS请求并回复:

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Headers: authorization

要了解有关CORS的更多信息,请参阅{{3}}。

答案 1 :(得分:0)

首次登录时,您最有可能在登录过程中的某处设置Authorization HTTP标头。另一方面,当用户退出时,您忘记删除此标题。

当您尝试再次登录时,Authorization HTTP标头仍然存在。这会触发浏览器执行预检请求(请参阅Rob W的解释:https://stackoverflow.com/a/27924344/548020。考虑到您尝试使用授权类型密码登录,发送Authorization标头没有意义,因为这样做意味着你已经被授权(=登录)。你基本上要求你的后端登录你,同时告诉你的后端你已经被授权(=登录)。

可以通过简单在用户注销时删除Authorization HTTP标头来解决此问题。

答案 2 :(得分:0)

在发送POST请求之前,您还可以在登录时清理标题:

delete $http.defaults.headers.common['Authorization'];