Trying to understand how to respond to CORS OPTIONS request with 403 and when

OPTIONS /frog/LOTS/upload/php.php HTTP/1.1Host: staff.curriculum.localUser-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip, deflateConnection: keep-aliveOrigin: http://frogserver.curriculum.localAccess-Control-Request-Method: POSTAccess-Control-Request-Headers: cache-control,x-requested-withPragma: no-cacheCache-Control: no-cache

Here is when I think I respond with 403:

1. If my origin set on the server is not * and not that domain, I respond with 403.
2. If I do not support POST (I may support GET), I respond with 403
3. If I do not support any one of the request headers, I respond with 403

For #1, if the domain is not supported, I will not send any Access-Control- headers in the response. I think that is OK.

For #2 and #3, I would send these headers assuming Origin request header was a match.

Access-Control-Allow-Origin: http://frogserver.curriculum.localAccess-Control-Allow-Credentials: {exists and is true IF supported on server}Access-Control-Allow-Headers: {all request headers we support and not related to incoming 'Access-Control-Request-Headers' in the request}Access-Control-Allow-Methods: {all methods supported NOT related to incoming method POST that came in?}Access-Control-Expose-Headers: {all headers we allow browser origin website to read}

Is my assumption correct here, or are some of the response headers related to the request headers in some way I am not seeing (the names are similar but I don't think the behavior is tied to each other)?

I would find it really odd that the request even needs to contain Access-Control-Request-Method and Access-Control-Request-Headers if we did not send back a 403 in the cases where we don't support all requested information on that endpoint, right? This is why I suspect we are supposed to return a 403 along with what we do support.