问题
The preflight is not supposed to happen for simple requests as per the documentation: https://developer.mozilla.org/en/docs/Web/HTTP/Access_control_CORS).
This is indeed the case if I don't put the additional "Authorization" header in the request:
"Content-Type": "application/x-www-form-urlencoded",
"Authorization": "Basic _base64_string_"
Without "Authorization" header:
:authority:www.target.com
:method:POST //<----------------This is correct
:path:/oauth2/access_token?client_id=xxx-xxx
:scheme:https
accept:application/json, text/plain, */*
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.8,fr;q=0.6
content-length:79
content-type:application/x-www-form-urlencoded//<----------------This is correct
origin:http://source.com:4200
referer:http://source.com:4200/
With "Authorization" header, OPTIONS method is automatically set:
:authority:www.target.com
:method:OPTIONS //<----------------This is NOT correct, caused by Authorization header
:path:/oauth2/access_token?client_id=xxx-xxx
:scheme:https
accept:*/*
accept-encoding:gzip, deflate, sdch, br
accept-language:en-US,en;q=0.8,fr;q=0.6
access-control-request-headers:authorization
access-control-request-method:POST
origin:http://source.com:4200
referer:http://source.com:4200/
Because of this issue, I am unable to authorize my app, the server response is :
HTTP method 'OPTIONS' is not allowed. Expected 'POST'
So it seems that the "Authorization" header triggers the preflight in CORS. Can anyone shed some light on this please?
回答1:
Because of this issue, I am unable to authorize my app, the server response is :
HTTP method 'OPTIONS' is not allowed. Expected 'POST'
If you have admin access to the server the request is being sent to, then you need to configure that server to allow HTTP OPTIONS requests, and to respond to them with the Access-Control-Allow-Headers and Access-Control-Allow-Methods response headers that browsers need to see in order to allow the actual GET or POST or whatever you’re trying to make (in addition to the Access-Control-Allow-Origin response header browsers need to see for the actual request).
If you don’t have admin access to that server to configure it to send that CORS-enabled response to OPTIONS requests, then your only option for getting requests from frontend JavaScript code to work with it is to set up a CORS proxy and make the request through that. The answer at "No 'Access-Control-Allow-Origin' header is present on the requested resource" has how-to details.
Your only other option beyond that is to not make the request from your frontend JavaScript code but to instead make it from your own backend code instead, which bypasses the cross-origin restrictions that browsers impose).
So it seems that the "Authorization" header triggers the preflight in CORS. Can anyone shed some light on this please?
Yeah, when you add the Authorization header, that makes it no longer a “simple request”.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests explains this; it says that one of the conditions that triggers the browser to do a preflight is:
If, apart from the headers set automatically by the user agent (for example,
Connection,User-Agent, or any of the other header with a name defined in the Fetch spec as a “forbidden header name”), the request includes any headers other than those which the Fetch spec defines as being a “CORS-safelisted request-header”, which are the following:Accept Accept-Language Content-Language Content-Type DPR Downlink Save-Data Viewport-Width Width
The Authorization is not in that list, so it triggers a preflight.
来源：https://stackoverflow.com/questions/44343288/angular-cors-simple-request-triggers-preflight-with-authorization-header-in-post