Preload generating CORS errors in console

[mitra42]

• Version: 0.30.1 pulled from GIT git://github.com/ipfs/js-ipfs.git#bffe080cd6c3fa202ca0437f8abe38dca75e5903
• Platform: Mac / Chrome
• Subsystem: preload

Type: Bug

Severity: unsure - probably

Description: preload is failing with CORS errors

Steps to reproduce the error:

I'm loading one of my existing demos, but am seeing repeated

Failed to load https://node0.preload.ipfs.io/api/v0/refs?r=true&arg=zdj7WiLc855B1KPRgV7Fh8ivjuAhePE1tuJafmxH5HmmSjqaD: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

I'm not intentionally preloading anything, but I noticed some messages about preloading pass by the lists recently, so I assume something changed.

The demo is broken, I don't think that's IPFS's fault, but it might be and given the closeness to the summit I thought someone might want to know.

[alanshaw]

Fixed here #1459 (comment) and in 4e50e70

[parkan]

this seems to come back intermittently, any ideas?

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=zdj7WkiVdkzBK8ponzCkE17CJdpsrxs28PGCTTuDPbhgCCXjg. (Reason: CORS request did not succeed). 

[alanshaw]

I believe this could still occur if the preload nodes are down. @lgierth is still true?

[parkan]

a scenario I've seen is when a service behind nginx, rather than nginx itself, generates the CORS headers, and that service goes down, we end up with nginx-generated messages without the right CORS (which then masks the underlying service failure)

could that be happening here?

By now nginx should be doing the CORS headers exclusively though, and go-ipfs shouldn't be setting them anymore.

I'll double-check this tomorrow.

[mitra42]

@lgierth - do you mean just for this (preload) case, or for all cases. Because we've also got an open bug where go-ipfs running locally (on a laptop) is denying access to local browser. ipfs-inactive/js-ipfs-http-client#855

Just talking about the preload.ipfs.io and ipfs.io cases, but I'll check that /version issue out too

[patientplatypus]

Seconding this problem - no idea why this is happening, but I've tried several different methods (see: https://gist.github.com/patientplatypus/a4adc9d1ae69fa7b3c67843ae8bab935) and I keep getting CORS errors. My code was working prior and I didn't change anything. I think this is a bug.

Here is the error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=QmcB5MvGmETQUQYeTbqd42HuN3kh1AReHwpk9BE45BXAMt. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node0.preload.ipfs.io/api/v0/refs?r=true&arg=QmcB5MvGmETQUQYeTbqd42HuN3kh1AReHwpk9BE45BXAMt. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=QmcB5MvGmETQUQYeTbqd42HuN3kh1AReHwpk9BE45BXAMt. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]

I have allow origins * in my config, so I don't think it can be client side...

[mitra42]

Just confirming this preload/CORS issue is still happening.

Although this might not be a CORS problem since its returning a "502 Bad Gateway" response, which (because it doesnt have cors headers) generates a cors error.

[mitra42]

The exact string is https://node1.preload.ipfs.io/api/v0/refs?r=true&arg=zdj7WePre4jBSvoCyAZQHJUCk7Jqin4fwGNKeMNE7st9Brebh