I'm storing my static files on different domain and I want my remote static server returns files with CORS headers, but my server should get "Origin" header in request to allow CORS headers. Unfortunately Chrome and FF doesn't send this header when I try load my js script with usual
<script type="text/javascript" src="https://my-another-static-server.com/js/script.js"></script>
When I see in Chrome's network panel I see only these request headers for this request:
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:ru,en-US;q=0.8,en;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Host:my-another-static-server.com
Pragma:no-cache
Referer:http://localhost:63342/example.html
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36
I know that browsers add Origin header for cross-domain request if we use XMLHttpRequest, but here we send request with native browsers technology.
There is tag crossorigin=anonymous that solved this problem. Now when I load script my browser also send Origin header.
Related
I am working on a JavaScript application, where I want to read data from an XML file and post them into a HTML file.
My code is producing the following error:
Request URL:http://myServer/dirs/dir/scripts/xml_data.xml
Request Method:POST
Status Code:405 Method Not Allowed
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en,en-US;q=0.8,da;q=0.6
Connection:keep-alive
Content-Length:13
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Host:myServer
Origin:http://myServer
Referer:http://myServer/dirs/dir/inWork.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Dataview sourceview URL encoded
node:xnode-24
Response Headersview source
Allow:GET, HEAD, OPTIONS, TRACE
Cache-Control:private
Content-Length:5309
Content-Type:text/html; charset=utf-8
Date:Thu, 12 Feb 2015 21:06:08 GMT
Server:Microsoft-IIS/8.0
X-Powered-By:ASP.NET
Based on this posting I created a new 'Handler Mapping' and I also adjusted the 'Handler Mapping' for 'StaticFile' to allow the methods: GET,HEAD,POST,DEBUG,PUT,DELETE.
The IIS server was restarted but still the error message appears and the only methods allowed are: GET, HEAD, OPTIONS, TRACE.
So, there is some configuration file or 'Handler Mapping' overriding my settings, or I simply did not consider.
Any suggestions on how to tell the IIS to accept my settings for this XMLHttpRequest?
My app needs to access a resources as in the Request URL however I can see in the Chrome network console that the request is GET (Cancelled)
Request URL:http://localhost:6001/_api/
Request Headers CAUTION: Provisional headers are shown.
Accept:application/json, text/javascript, */*; q=0.01
Cache-Control:max-age=0
Origin:http://127.0.0.1:6001
Referer:http://127.0.0.1:6001/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/33.0.1750.152 Chrome/33.0.1750.152 Safari/537.36
Is there anything wrong in the request? If I access the Request URL and paste it in the browser, the JSON string is returned properly. What could be the reason?
Update:
Prior to the request above here there is a request for this:
Request URL:http://localhost:6001/_api/_session
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:accept
Access-Control-Request-Method:DELETE
Cache-Control:max-age=0
Connection:keep-alive
Host:localhost:6001
Origin:http://127.0.0.1:6001
Referer:http://127.0.0.1:6001/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/33.0.1750.152 Chrome/33.0.1750.152 Safari/537.36
Response Headersview source
access-control-allow-headers:Authorization, Content-Type, If-None-Match
access-control-allow-methods:GET, HEAD, POST, PUT, DELETE, OPTIONS
access-control-allow-origin:*
access-control-expose-headers:WWW-Authenticate, Server-Authorization
access-control-max-age:86400
cache-control:no-cache
Connection:keep-alive
content-encoding:gzip
content-type:application/json; charset=utf-8
Date:Sun, 06 Apr 2014 04:26:37 GMT
Transfer-Encoding:chunked
vary:accept-encoding
But the status was: A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://127.0.0.1:6001' is therefore not allowed access.
You are mixing 127.0.0.1 and localhost which could make it look like xss. Use one or the other but not both.
So I understand how a manifest file works and I am getting all the resource I need from the network tab in Chrome's developer console. When I turn off my server and run the webpage offline it works. But after the first refresh the page has the error HTTP Error 404. The requested resource is not found. I check what file was missing and it was the text/html that was the webpage and when I check the header
Request URL:https://offline1.exactbid.net/
Request Method:GET
Status Code:404 Not Found
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:offline1.exactbid.net
Referer:https://offline1.exactbid.net/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36
Response Headersview source
Connection:close
Content-Length:315
Content-Type:text/html; charset=us-ascii
Date:Fri, 28 Jun 2013 23:09:27 GMT
Server:Microsoft-HTTPAPI/2
UPDATE
So it seems that after I refresh the page everything I had in the appcache disappeared. Does it have to do with the Cache-Control:max-age=0, I read some stuff online and it says that it is similar to no-cache. is that correct?
It seems that when I try to start the page offline it says that the cache is obsolete
OK after experimenting I figure the what but not the why. I was using ASP. net for the web page and I did not have a site master page so I was declaring it in my default.aspx directly. But after I changed my code to have a site master page and declares the manifest file there it fixed the problem. When I am offline and refresh the manifest download fails (suppose to happen) and does not label the appcache as obsolete. I hope this helps someone. If someone knows the why I would mark that as the answer until then this is it
We have an SPA that draws more javascript modules from a separate backend server, assisted by Require.js. By nature of the XHR loading procedure, pre-flight OPTIONS requests are made to the backend server and the Access-Control-Allow-Origin response is perfectly valid. The process of login and initial module loading work just fine, as expected.
XHR finished loading: "http://backend.cloudapp.net/api/modules/resourceA".
XHR finished loading: "http://backend.cloudapp.net/api/modules/resourceB".
Funny thing is, certain subsequent actions that call for more modules would unexpectedly raise a CORS error in Chrome.
XMLHttpRequest cannot load
http://backend.cloudapp.net/api/modules/resourceC. Origin
https://frontend.cloudapp.net is not allowed by
Access-Control-Allow-Origin.
Which does not make sense, since the previous modules loaded just fine. Even the actual OPTIONS preflight came back proper for resourceC. Some other places in the UI have their modules loading fine too. And Firefox does not appear to suffer from this problem. Has anybody experienced similar CORS errors?
Request/response headers for successful (expected) module
Request URL:http://backend.cloudapp.net/api/modules/resourceA
Request Method:OPTIONS
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Access-Control-Request-Headers:accept, origin, content-type
Access-Control-Request-Method:GET
Host:backend.cloudapp.net
Origin:https://frontend.cloudapp.net
Proxy-Connection:keep-alive
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Response Headers
Access-Control-Allow-Headers:accept, origin, content-type
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:https://frontend.cloudapp.net
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:0
Date:Wed, 19 Jun 2013 07:12:42 GMT
Expires:-1
Pragma:no-cache
Proxy-Connection:Keep-Alive
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Request URL:http://backend.cloudapp.net/api/modules/resourceA
Request Method:GET
Status Code:200 OK
Request Headers
Accept:application/json
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Content-Type:application/json
Host:backend.cloudapp.net
Origin:https://frontend.cloudapp.net
Proxy-Connection:keep-alive
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Response Headers
Access-Control-Allow-Origin:https://frontend.cloudapp.net
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:5048
Content-Type:application/json; charset=utf-8
Date:Wed, 19 Jun 2013 07:12:42 GMT
Expires:-1
Pragma:no-cache
Proxy-Connection:Keep-Alive
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Request/response headers for unsuccessful module
Request URL:http://backend.cloudapp.net/api/modules/resourceC
Request Method:OPTIONS
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Access-Control-Request-Headers:accept, origin, content-type
Access-Control-Request-Method:GET
Host:backend.cloudapp.net
Origin:https://frontend.cloudapp.net
Proxy-Connection:keep-alive
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Response Headers
Access-Control-Allow-Headers:accept, origin, content-type
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:https://frontend.cloudapp.net
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:0
Date:Wed, 19 Jun 2013 07:12:59 GMT
Expires:-1
Pragma:no-cache
Proxy-Connection:Keep-Alive
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Request URL:http://backend.cloudapp.net/api/modules/resourceC
Request Headers
Accept:application/json
Content-Type:application/json
Origin:https://frontend.cloudapp.net
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
(And browser blocks further action)
Given that Chrome has gone through so many version updates, in addition to us deploying some module resources in a different package manner now in different AWS infrastructure, we no longer experience this problem now.
Inspired from my answer here
It might be worth investigating if any of the failing XHRs are sending any peculiar unicode character. In our case, one of our user's name contained a unicode character and our HTTP proxy wasn't handling it properly thereby leading to a CORS error.
I see quite a lot posts with regards to this topic but still can't find a solution for my case.
I want to leverage the caching of the images for our web site (hosted in IIS 7.5). I did configure the caching through "http response headers" menu in IIS management console and it works for images with "absolute" src like <img src="images/logo.png" alt="Logo"> but it doesn't work for images with JSON source e.g. <img alt="Image" src="http://myhost.com/site/Services/Service.svc/images/im0002/thumb" > that is set dynamically in the ajax callback.
Detailed request/response headers:
Request URL:http://myhost.com/site/Services/Service.svc/images/im0002/thumb
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:/
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:myhost
Referer:http://myhost/site/Default.aspx
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11
Response Headersview source
Content-Length:1392
Content-Type:image/jpeg
Date:Fri, 27 Jul 2012 07:37:25 GMT
Server:Microsoft-IIS/7.5
X-Powered-By:ASP.NET
Any information about how to fix that is highly appreciated.
Convert your image into Base64 or anything similar. It will be a string by then, no longer a url.