Gitpod: Can't open Gitpod due to CORS errors
Describe the bug
I received a report that Gitpod can not be opened on several devices due to these errors:
To Reproduce
I don't know :/
Expected behavior
Gitpod should load.
Analysis
When I open https://gitpod.io/workspaces/ I can also see requests to
https://unpkg.com/react@16/umd/react.production.min.js and
https://unpkg.com/react-dom@16/umd/react-dom.production.min.js
which are being redirected to
https://unpkg.com/[email protected]/umd/react.production.min.js
https://unpkg.com/[email protected]/umd/react-dom.production.min.js
However, for me, the server includes access-control-allow-origin: * into all four responses and therefore there is no error.
Possible causes:
- weird behaviour of unpkg.com
- custom browser or proxy settings.
meysholdt
All 13 comments
Getting the same error
Access to script at 'https://unpkg.com/[email protected]/umd/react-dom.production.min.js' (redirected from 'https://unpkg.com/react-dom@16/umd/react-dom.production.min.js') from origin 'https://gitpod.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
URL at https://unpkg.com/[email protected]/umd/react-dom.production.min.js doesn't seem to have Access-Control-Allow-Origin: *
Edit: Adding terminal outputs
$ curl --head 'https://unpkg.com/react-dom@16/umd/react-dom.production.min.js'
HTTP/1.1 302 Found
Date: Sun, 27 Jan 2019 14:31:01 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 71
Connection: keep-alive
Access-Control-Allow-Origin: *
Location: /[email protected]/umd/react-dom.production.min.js
Vary: Accept
Via: 1.1 google
Cache-Control: public, s-maxage=14400, max-age=3600
CF-Cache-Status: HIT
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 49fbeba7e9c28a5b-BOM
$ curl --head 'https://unpkg.com/[email protected]/umd/react-dom.production.min.js'
HTTP/1.1 200 OK
Date: Sun, 27 Jan 2019 14:30:38 GMT
Content-Type: application/javascript; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: public, max-age=31536000
Last-Modified: Sun, 27 Jan 2019 06:52:22 GMT
ETag: W/"189cd-1688e149c70"
Via: 1.1 google
CF-Cache-Status: HIT
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 49fbeb18dd428a4f-BOM
frextrite
on 27 Jan 2019
Related https://github.com/unpkg/unpkg.com/issues/174
and https://github.com/unpkg/unpkg.com/issues/23
we probably should not rely on on unpkg.com.
svenefftinge
on 27 Jan 2019
Seems like this happens more often:
svenefftinge
on 27 Jan 2019
It's odd that this behavior isn't consistent. I was using Gitpod without issue on Friday, but then last night I couldn't reach it. I had tried from browserling.com, which also didn't work last night, but is working now.
I currently can't reach https://gitpod.io from my chromebook, my android phone running chrome, or my wife's iPhone.
Curl shows the "access-control-allow-origin" header on https://unpkg.com/react-dom@16/umd/react-dom.production.min.js but not on the file it redirects to https://unpkg.com/[email protected]/umd/react-dom.production.min.js (results below).
Since it's working for some users and not others I'm guessing that different parts of unpkg's CDN are returning different headers.
$ curl --head 'https://unpkg.com/react-dom@16/umd/react-dom.production.min.js'
HTTP/2 302
date: Sun, 27 Jan 2019 14:24:40 GMT
content-type: text/plain; charset=utf-8
content-length: 71
access-control-allow-origin: *
cache-control: public, s-maxage=14400, max-age=3600
location: /[email protected]/umd/react-dom.production.min.js
vary: Accept
via: 1.1 google
cf-cache-status: HIT
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 49fbe25b2c68c190-IAD
$ curl --head 'https://unpkg.com/[email protected]/umd/react-dom.production.min.js'
HTTP/2 200
date: Sun, 27 Jan 2019 14:25:02 GMT
content-type: application/javascript; charset=UTF-8
vary: Accept-Encoding
cache-control: public, max-age=31536000
last-modified: Sun, 27 Jan 2019 06:52:22 GMT
etag: W/"189cd-1688e149c70"
via: 1.1 google
cf-cache-status: HIT
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 49fbe2e5dc88c181-IAD
sherbang
on 27 Jan 2019
It also seems to be per region, as it works flawlessly for me (northern Germany).
± |master ✓| → curl --head 'https://unpkg.com/[email protected]/umd/react-dom.production.min.js'
HTTP/2 200
date: Sun, 27 Jan 2019 14:32:40 GMT
content-type: application/javascript; charset=utf-8
content-length: 100813
access-control-allow-origin: *
cache-control: public, max-age=31536000
last-modified: Sat, 26 Oct 1985 08:15:00 GMT
etag: "189cd-8IC0bEVyhubTK5FZT1Li+vmc13E"
via: 1.1 vegur
cf-cache-status: HIT
accept-ranges: bytes
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 49fbee12eb6c7008-SIN
Tried via VPN over india and canada but both look good.
svenefftinge
on 27 Jan 2019
I tried the curl command from my other ISP(cellular network) and was able to access the website, here's the output:
$ curl --head 'https://unpkg.com/[email protected]/umd/react-dom.production.min.js'
HTTP/1.1 200 OK
Date: Sun, 27 Jan 2019 14:41:04 GMT
Content-Type: application/javascript; charset=utf-8
Content-Length: 100813
Connection: keep-alive
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=31536000
Last-Modified: Sat, 26 Oct 1985 08:15:00 GMT
Etag: "189cd-8IC0bEVyhubTK5FZT1Li+vmc13E"
Via: 1.1 vegur
CF-Cache-Status: HIT
Accept-Ranges: bytes
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 49fbfa6418446f8a-SIN
The only difference I can see is the "Via" header.
Via: 1.1 vegur has the Access-Control-Allow-Origin header whereas Via: 1.1 google does not.
frextrite
on 27 Jan 2019
I was able to get to it form my cellphone once I disconnected from wifi. I also was able to get the header using curl from Google's compute engine network.
The one that isn't working is a charter.com connection in the US.
Here's traceroute retults to unpkg.com (omitted the first 2 hops for privacy):
3 * * *
4 96-34-141-202.static.unas.mo.charter.com (96.34.141.202) 18.322 ms 19.208 ms 19.423 ms
5 crr01wrcsma-tge-0-5-0-1.wrcs.ma.charter.com (96.34.80.240) 21.786 ms crr02asfdct-tge-0-2-0-1.asfd.ct.charter.com (96.34.81.60) 20.646 ms crr01wrcsma-tge-0-5-0-1.wrcs.ma.charter.com (96.34.80.240) 21.244 ms
6 bbr01oxfrma-bue-2.oxfr.ma.charter.com (96.34.2.14) 22.977 ms 30.453 ms bbr01nwtwct-bue-3.nwtw.ct.charter.com (96.34.2.160) 32.919 ms
7 bbr01blvlil-tge-0-0-0-11.blvl.il.charter.com (96.34.0.137) 40.022 ms 30.832 ms 34.596 ms
8 prr01ashbva-bue-6.ashb.va.charter.com (96.34.3.89) 30.203 ms bbr01blvlil-tge-0-0-0-11.blvl.il.charter.com (96.34.0.137) 37.797 ms 38.761 ms
9 prr01ashbva-bue-6.ashb.va.charter.com (96.34.3.89) 31.992 ms 206.126.237.30 (206.126.237.30) 57.959 ms prr01ashbva-bue-6.ashb.va.charter.com (96.34.3.89) 31.070 ms
10 104.16.126.175 (104.16.126.175) 29.045 ms 206.126.237.30 (206.126.237.30) 58.773 ms 59.124 ms
Note: all effected pages show as completely blank. It might be nice to show some kind of content or error or something to the user when these scripts can't load.
sherbang
on 27 Jan 2019
We are replacing the CDN usage.
svenefftinge
on 27 Jan 2019
done. gitpod.io no longer uses the CDN. Everything should work just fine now.
meysholdt
on 27 Jan 2019
Thank you @sherbang and @frextrite for confirming this and for analysis. That was helpful to resolve this quickly!
meysholdt
on 27 Jan 2019
Glad to be of assistance.
frextrite
on 27 Jan 2019
Related issues
Kreyren
·
3Comments
ColbyWTaylor
·
3Comments
Kreyren
·
3Comments
hidehiro98
·
3Comments
kuniss
·
3Comments
Most helpful comment
Note: all effected pages show as completely blank. It might be nice to show some kind of content or error or something to the user when these scripts can't load.