Firefox v. Safari understanding D3 differently? Print different things in console log ??
122 views
Skip to first unread message
Maggie Lee
Nov 23, 2012, 12:54:40 AM11/23/12
to d3...@googlegroups.com
So I run a little snippet, print some text in the console.
Firefox 12.0 thinks my .csv is "null."
But Safari 6.0.2 correctly prints the .csv data in the console.
Fun fact:
My FF automatically downloads csvs.
My Safari automatically opens csvs.
<html>
<head>
<title>D3 Test</title>
<script type="text/javascript" src="d3/d3.v2.js"></script>
</head>
<body>
<script type="text/javascript">
d3.csv(url, function(data)
{
console.log("hey"); //this prints "hey" in both FF & Safari console
console.log(data); //this prints "null" in FF, prints the data in Safari
});
</script>
</body>
</html>
Best & thanks!!!
-Maggie
Miguel Pignatelli
Nov 23, 2012, 4:57:39 AM11/23/12
to d3...@googlegroups.com
You are most probably having a cross-domain XMLHttpRequest issue
I tried to run your code both in Chrome and Firefox. Chrome fails with that specific error:
XMLHttpRequest cannot load http://greencracker.net/wp-content/uploads/2012/11/sandbox.csv. Origin http://localhost:12345 is not allowed by Access-Control-Allow-Origin
Firefox gives a "200 OK" status but the response is empty.
I didn't know that Safari allows this.
Anyway, I suggest you to serve the csv file locally.
Cheers,
M;
Maggie Lee
Nov 23, 2012, 9:17:03 AM11/23/12
to d3...@googlegroups.com
Hm. Very far outside my experience!
Then a followup, if I may:
Where/how would I eventually host a .csv for a graph that goes on my website?
I have got to put the graph & the .csv in the same domain?
That is eminently doable.
That is eminently doable.
Thanks!
Miguel Pignatelli
Nov 23, 2012, 9:36:01 AM11/23/12
to d3...@googlegroups.com
On Friday, 23 November 2012 14:17:04 UTC, Maggie Lee wrote:
Hm. Very far outside my experience!Then a followup, if I may:Where/how would I eventually host a .csv for a graph that goes on my website?
Easiest way is to have it local in the web server you are using (where the html files are).
M;
Scott Cameron
Nov 23, 2012, 11:37:54 AM11/23/12
to d3...@googlegroups.com
Hi Maggie,
You're likely bumping up against the same origin policy for script-driven requests. It means that a script can only freely request resources from the origin domain of the script itself. Requests to other domains are disallowed unless those other domains explicitly allow requests either from all other origins or from the particular origin of your script.
In your case, it means that you need to configure the web server at greencracker.net to allow localhost:12345 as an acceptable origin. I'm not sure why Firefox and Safari are working.
Here's more information about the mechanism you can use to allow limited cross-domain access: CORS.
And here's a page that shows how to configure it on common web servers: enable-cors.org
Cheers,
scott
Benjamin West
Nov 23, 2012, 3:06:36 PM11/23/12
to d3...@googlegroups.com
Maggie,
I think you have the right idea.
The basic idea at work is that any "ajax" request, which is what
d3.csv does, has to come from the same domain and port as the webpage
that showing the content. CORs is a fancy way to negotiate work
arounds, but the simple workflow goes like this:
For development, it's custom for people to use localhost:8080, or
something similar for everything, both web page and data.
In testing, or for sharing, it's customary for people to use a service
like http://bl.ocks.org/ so that both the data and the webpage get
served from the same place. You can test it out by uploading your
test to gist.github.com and viewing it on blocks. This is often a
great way to get help, since everyone is able to see and work on the
same problem.
In your case, it's probably just as easy to make the data available
from the same port and domain as the webpage, if not there is CORs.
In "production" this is exactly what people do, just as you suggested.
You will find that jQuery.ajax and friends all have similar
restrictions, it's a safety feature.
-bewest
P.S. In really fancy environments, you might use several webservers to
either proxy or "reverse-proxy" to the right services, or in
restrictive environments you might find something like http://xip.io/
handy.
I think you have the right idea.
The basic idea at work is that any "ajax" request, which is what
d3.csv does, has to come from the same domain and port as the webpage
that showing the content. CORs is a fancy way to negotiate work
arounds, but the simple workflow goes like this:
For development, it's custom for people to use localhost:8080, or
something similar for everything, both web page and data.
In testing, or for sharing, it's customary for people to use a service
like http://bl.ocks.org/ so that both the data and the webpage get
served from the same place. You can test it out by uploading your
test to gist.github.com and viewing it on blocks. This is often a
great way to get help, since everyone is able to see and work on the
same problem.
In your case, it's probably just as easy to make the data available
from the same port and domain as the webpage, if not there is CORs.
In "production" this is exactly what people do, just as you suggested.
You will find that jQuery.ajax and friends all have similar
restrictions, it's a safety feature.
-bewest
P.S. In really fancy environments, you might use several webservers to
either proxy or "reverse-proxy" to the right services, or in
restrictive environments you might find something like http://xip.io/
handy.
Maggie Lee
Nov 23, 2012, 5:43:40 PM11/23/12
to d3...@googlegroups.com
Thanks everyone for your help!
Teh interwebz r magick
Reply all
Reply to author
Forward
0 new messages