5

I understand CORS and how to set the appropriate Access-Control-* headers on a server response. The problem I'm finding is that even though my server is responding with Access-Control-Allow-Origin:*, Chrome is refusing to accept the response.

OPTIONS request:

OPTIONS /api/shows/1 HTTP/1.1
Host: *****
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost:8888
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36
Access-Control-Request-Headers: accept, platform, version
Accept: */*
Referer: http://local host:8888/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8

Response:

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 0
Content-Type: */*
Content-Encoding: gzip
Expires: -1
Server: Microsoft-IIS/8.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type, Platform, Version
Access-Control-Allow-Methods: OPTIONS, TRACE, GET, HEAD, POST, PUT, DELETE
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 03 Oct 2014 19:07:28 GMT

In the debug console, Chrome displays:

XMLHttpRequest cannot load http://****/api/shows/1. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'localhost:8888' is therefore not allowed access.

Obviously, there is an Access-Control-Allow-Origin in the response, but for some reason Chrome thinks it is invalid? Is there a condition where I cannot use the wildcard for this response?

Thanks in advance!

providencemac
  • 612
  • 6
  • 14
  • 2
    Is your browser also sending an *actual* request after the preflight request? Or is your end goal truly to read an OPTIONS response (i.e., your Ajax code does `xhr.open("OPTIONS", "/api/shows/1")`) and you think this *is* the actual request? (Even then, this is still a preflight, because OPTIONS is a non-simple HTTP method, but that would be a heck of a lot more confusing for you.) – apsillers Oct 03 '14 at 19:31
  • Yes, the browser follows with a GET request, but it is abandoned. Thanks for the thought. – providencemac Oct 03 '14 at 19:39
  • 1
    Just to be 100% clear, by "abandoned" you mean the GET request is never sent? (In the Chrome network inspector it turns red?) – apsillers Oct 03 '14 at 19:46
  • Yes, that is what I mean. The GET request is displayed in red, has no response and shows a "Provisional headers are shown" message – providencemac Oct 03 '14 at 19:58
  • The only possible problem I can quickly spot is that your browser sends `accept` as a request header in `Access-Control-Request-Headers` but it's not allowed in `Access-Control-Allow-Headers`. I'm not sure why it's even in there, because `Accept` is a simple request header, but maybe that's causing the rejection? – apsillers Oct 03 '14 at 20:04
  • Thanks, i'll see if I can forcibly remove it and try again – providencemac Oct 03 '14 at 20:42
  • Or just add it to the allowed headers. – apsillers Oct 03 '14 at 20:48
  • "Is there a condition where I cannot use the wildcard for this response?" Yes, but i doubt you're running into that here. you can't use * if you're sending cookies, http authorization, or ssl. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing – Kevin B Oct 03 '14 at 21:45

3 Answers3

5

In this case, I solved the issue by also including the Access-Control-* headers in the GET response as well. Based on my understanding of the spec, this should not be required, but the problem was resolved this way.

If anyone has an explanation for this I would love to hear it

providencemac
  • 612
  • 6
  • 14
  • 1
    The actual request has to pass "Resource Sharing Check" as well, so the `GET` response has to have the CORS headers. This documented in https://www.w3.org/TR/2020/SPSD-cors-20200602/#actual-request. It is also mentioned in this post - https://stackoverflow.com/a/10636765/709065. – lovelywib Jul 26 '20 at 06:34
0

Access-Control-Request-Headers are case sensitive... accept should be Accept

Beckafly
  • 411
  • 2
  • 5
  • Can you provide a citation for this? I see no mention of header case-sensitivity in the W3c spec: http://www.w3.org/TR/cors/ Also, Chrome is automatically changing header names to lowercase in the pre-flight, so I would be very surprised if this is the case – providencemac Oct 04 '14 at 13:30
  • 4
    From http://www.html5rocks.com/en/tutorials/cors/ HTTP Headers matches (case-insensitive): Accept Accept-Language Content-Language Last-Event-ID Content-Type, but only if the value is one of: application/x-www-form-urlencoded multipart/form-data text/plain – Beckafly Oct 04 '14 at 18:26
-4

Go to the “Desktop” select the “Google chrome” icon and “right click” on it, then go to its “Properties”

Here in Properties find the input box with label “Target” in this box the location of chrome is given as follows.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="c:/someFolderName"

Finally, launch the Chrome freshly to see a pop-up with yellow colour on the top of the screen

source: https://www.thegeekstuff.com/2016/09/disable-same-origin-policy/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%253A+TheGeekStuff+(The+Geek+Stuff)

good luck

hiba akroush
  • 11
  • 2
  • 1
    Thanks for the attempt, however this is not a solution to the problem, but rather a method to completely disable a very important browser security feature. I do not recommend anyone follow this option, as it will open your browser to cross site scripting attacks across ALL sites. Also, if applying this "just for development" you will falsely think you've fixed problems in your software, but users in production will still have problems – providencemac Apr 19 '19 at 14:56