What is the reason behind using OPTION request before POST on CORS requests?
<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>