How does the Chrome browser decide to send OPTIONS?

Question

I have an AngularJS WebAPI application.

As I understand it, an OPTIONS request is automatically created 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 

Answer:

 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 .... 70O93wsipJkLUZuNdwC8tZc5M0o1ifoCjvnRXKjEBk3nLRbFlbldJLydW2BWonr5JmBjRjXZyKtcc29ggAVhZlc2E-3gGDlyoZLAa5Et8zrAokl8vsSoXmHnsjrxZw0VecB_Ry98Ln84UuKdeHlwSBnfaKKJfsN-u3Rsm6MoEfBO5aAFEekhVBWytrYDx5ks-iVok3TjJgaPc5ex53kp7qrtH3izbjT7HtnrsYYtcfPtmsxbCXBkX4ssCBthIl-NsN2wObyoEqHMpFEf1E9sB86PJhTCySEJoeUJ5u3juTnPlQnHsk1UTcO0tDb39g-_BD-I4FWS5GMwxLNtmut3Ynjir0GndwqsvpEsLls1Y4Pq7UuVCTn7DMO4seb64Sy8oEYkKZYk9tU4tsJuGD2CAIhdSc-lAmTAA78J5NOx23klkiuSe_SSiiZo5uRpas_1CFHjhi1c8ItEMpgeTsvgTkxafq5EOIWKPRxEHbCE8Dv106k5GlKK5BaH6z7ESg5BHPBvY8; 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 of the system, it is nothing like deleting a token and logging in again. Something is happening, it's different. Before he sent the OPTIONS, but now he does. Is there something as a result of the previous request / response that will affect the browser acting differently 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 

Answer:

 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 reset the browser and reload the page, then it returns as before, when it does not send OPTIONS for the first time, and I can log in.

Perhaps I need to change something on the server so that it processes the parameters.

BUT, why is my browser (Chrome) not sending OPTIONS for the first time?

Answer 1

Does the browser (or any other browser) send an OPTIONS request exactly CORS specfication :

When the cross-start query algorithm is called, do the following: ...
2. If the following conditions are met, follow the algorithm of a simple cross-origin algorithm :

• the request method is a simple method and it is not set to force the pre-flight flag .

• Each of the author’s request headers is a simple heading or the author’s request headers are empty.

3. Otherwise, follow the cross origin request with a preliminary algorithm .
Note. Cross-origin requests using the simple method with non- simple author request headers will have a preflight request to ensure that the resource can handle these headers. (Similar to queries using a method that is not a simple method .

The OPTIONS request contains the following request header:

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

This means that your Angular application has inserted a <=> simple Authorization request header, possibly as part of an authentication scheme. The complex "author request headers" trigger an OPTIONS request, as you can see in the above quote.

For the request to be successful, your server must process the OPTIONS request and respond:

 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 .

Answer 2

The first time you log in, you most likely set the Authorization HTTP header somewhere in your login procedure. On the other hand, you forget to delete this header when the user logs out.

When you log in again, the HTTP Authorization header is still present. This forces the browser to complete the request before flying (see Rob W's explanation: fooobar.com/questions/821606 / .... Given that you are trying to log in with a grant type password, it does not make sense to send an Authorization header, since this means that you are already authorized (= logged in.) Basically, you request that your server register you and at the same time inform your server that you are already logged in (= logged in).

This can be fixed by simply removing the HTTP Authorization header when the user logs out .

Answer 3

You can also clear the headers on login before sending a POST request:

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