title: How does the Chrome browser decide when to send OPTIONS?
body: <p>I have an AngularJS WebAPI application.</p>
  
  <p>As far as I can understand the OPTIONS request is constructed automatically by the browser. </p>
  
  <pre><code>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&amp;username=xxx%40live.com&amp;password=xxx
  </code></pre>
  
  <p>Response:</p>
  
  <pre><code>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 ....
  </code></pre>
  
  <p>Now logged in</p>
  
  <p>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?</p>
  
  <pre><code>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
  </code></pre>
  
  <p>Response:</p>
  
  <pre><code>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"}
  </code></pre>
  
  <p>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. </p>
  
  <p>Probably I need to change something on the server so it handles options. </p>
  
  <p>BUT why does my browser (Chrome) not send OPTIONS the first time?</p>