Access-Control-Allow-Origin header not working - W

2019-02-03 13:47发布

问题:

I am attempting to provide a response to the HTTP OPTIONS method with an Access-Control-Allow-Origin header copying the contents of the Origin header in the request.

This is apparently not working, for reasons I can't figure out.

tl;dr: response from OPTIONS says:

Access-Control-Allow-Origin: http://10.0.0.105:9294

subsequent GET has:

Origin:http://10.0.0.105:9294

Chrome says:

Origin http://10.0.0.105:9294 is not allowed by Access-Control-Allow-Origin

WTF not?

More detail...

By looking in Chrome's developer tools window, the request headers are:

OPTIONS /user/kris HTTP/1.1
Host: 10.0.0.104:8080
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://10.0.0.105:9294
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1
Access-Control-Request-Headers: origin, x-requested-with, content-type, accept
Accept: */*
Referer: http://10.0.0.105:9294/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

The response headers are:

HTTP/1.0 200 OK
Date: Mon, 13 Aug 2012 11:23:45 GMT
Server: WSGIServer/0.1 Python/2.7.3
Content-Length: 0
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD, OPTIONS
Access-Control-Max-Age: 10
Access-Control-Allow-Origin: http://10.0.0.105:9294
Access-Control-Allow-Headers: X-Requested-With, Authorization, X-Huzu-User, Content-Type, Accept
Content-Type: text/html; charset=UTF-8

After jQuery sends its OPTIONS request and gets the above response, 2 odd things happen. The OPTIONS response (which is a 200) shows up in the developer console as an error:

OPTIONS http://10.0.0.104:8080/user/kris 200 (OK)

After which a GET request is rejected. Error in the console:

XMLHttpRequest cannot load http://10.0.0.104:8080/user/kris. Origin http://10.0.0.105:9294 is not allowed by Access-Control-Allow-Origin.

I can't see why not. What am I doing wrong?

回答1:

OK, I think I've got it. It seems that proper handling of the pre-flight OPTIONS request is necessary, but NOT SUFFICIENT for cross-site resource requests to work.

After the OPTIONS request comes back with satisfactory headers, all responses to any subsequent requests to the same URL also have to have the necessary "Access-Control-Allow-Origin" header, otherwise the browser will swallow them, and they won't even show up in the debugger window.

So it will look like the browser cancelled the request because of some problem in the OPTIONS response, but actually, the browser is looking at the response headers from the real request and then rejecting them.