title: What is the reason behind using OPTION request before POST on CORS requests?
body: <p>What is the reason behind sending an <code>OPTION</code> request before the actual <code>POST</code>, <code>UPDATE</code>, <code>PUT</code> or <code>DELETE</code> request when a different domain is called? (So on CORS requests) I know it supposed to check whether the server can process the real request but why not send just the real request immediately? </p>
  
  <p>Some of the reasons I have thought about:</p>
  
  <ol>
  <li><strong>See if the method is supported</strong> 
  
  <ul>
  <li>Sending the real request will return the same status code, so
  no need to send <code>OPTION</code> request first.</li>
  </ul></li>
  <li><strong>Check if the user allowed to send the request</strong>
  
  <ul>
  <li>Make no sense as no auth headers are sent with the <code>OPTION</code> requests</li>
  </ul></li>
  <li><strong>Prevent heavy load on the server</strong> 
  
  <ul>
  <li>Make no sense, as checking the auth rules is before the processing of the data.</li>
  </ul></li>
  <li><strong>To check if requested headers and origin are allowed</strong>
  
  <ul>
  <li>This is how it works now, but again why not just send the request, and we can read the error from the real request. </li>
  </ul></li>
  <li><strong>Prevent sending the post data, if it wont be processed</strong>
  
  <ul>
  <li>This is the only reason what is valid. Using options request will prevent sending the post data to the server unnecessarily. However I think this is not a problem in the 99% of the time, as only a small chunk of data is sent. </li>
  </ul></li>
  </ol>
  
  <p>Can someone shed some light on the reasons why browser vendors implemented <code>OPTION</code> requests when calling a different domain? </p>