XMLHttpRequest cannot load http://127.0.0.1:8081/feeds.json. Request header field Authorization is not allowed by Access-Control-Allow-Headers in preflight response
$ http-server --cors
Starting up http-server, serving ./
Available on:
http://127.0.0.1:8081
http://192.168.1.3:8081
Here are the headers:
Response Headers
access-control-allow-headers:Origin, X-Requested-With, Content-Type, Accept, Range
access-control-allow-origin:*
Connection:keep-alive
Date:Sun, 03 Sep 2017 07:51:28 GMT
Request Headers
view source
Accept:*/*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:authorization
Access-Control-Request-Method:GET
This is the OPTIONS request in chrome that is failing.
--cors works fine for me.
Check your request headers whether there are headers not in Origin, X-Requested-With, Content-Type, Accept, Range
I had to pass --cors=Authorization
--cors option do nothing for me. I have tried http-server --cors and http-server --cors='*'
No success
I believe I am having the same issue. Passing --cors the cross-origin request still fails
Same problem here.
@TeodorKolev @ansermino @Kazanz are you all simply using --cors (without a value or with '*' in @TeodorKolev's case)?
The test for this feature is here:
https://github.com/indexzero/http-server/blob/413fe72f8da11c7c5746d16e4a7876450f2d9d8c/test/http-server-test.js#L128-L156
Please extend it to test your scenario/usage expectation and lets see what we can figure out! 馃槂
@BigBlueHat After fiddling around turns out CORS was working in Firefox but not in chrome, because of the capitalization of the header.
This one works for me: http-server {folder} --cors=http://localhost:3000/
@BigBlueHat After fiddling around turns out CORS was working in Firefox but not in chrome, because of the capitalization of the header.
Capitalization of the CORS Access-* headers? or of the header passed in via --cors=? HTTP headers are not case sensitive, so it would surprise me if Chrome were failing for that reason.
We'll need to narrow down the scenario and test it before we change the code for this feature. Thanks!
This one works for me: http-server {folder} --cors=http://localhost:3000/
@PhilTheAir the --cors takes a list of HTTP Headers. It's currently not possible to narrow the Access-Control-Allow-Origin header to something less than *. If you need that, please file another issue for it--as it's likely useful to others! See https://github.com/indexzero/http-server/blob/master/lib/http-server.js#L69-L79 for codez.
This is potentially unrelated to some of the more specific comments, but in general if you're only testing in browser, the default caching of one hour can cause the non-cors response to be cached and fail to get the new cors response.
I'm having a problem with reading headers within an XHR request in Chrome. 'Access-Control-Expose-Headers' needs to be supported as well.
https://github.com/mozilla/pdf.js/issues/3150#issuecomment-17582371
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers
I had the same problem. I solved it by installing cors global npm install cors -g.
--cors without value works, probably browser cache issue, hit ctrl + f5
It may be the cause of browser caching.
I solved the reason why cros did not work, and forced to refresh the browser by ctrl+F5
same issue here. tried npx http-server --cors='*',--cors, --cors=Authorization, tried hard-refreshing the browser and clearing the cache, tried in multiple browsers...still getting the following issue.
Access to fetch at 'http://www.theurliwanttofetch.com' from origin 'http://127.0.0.1:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Most helpful comment
I had to pass
--cors=Authorization