Improve Cloudfront config
dabreegster opened this issue · 7 comments
Broken: http://play.abstreet.org/0.3.43/santa.html
Working: http://abstreet.s3-website.us-east-2.amazonaws.com/0.3.43/santa.html
Started loading WASM [santa.bundle.js:83:21](http://play.abstreet.org/0.3.43/santa/santa.bundle.js)
19:26:51.623 state change: loading -> error [santa.bundle.js:166:17](http://play.abstreet.org/0.3.43/santa/santa.bundle.js)
19:26:51.638 Assertion failed: not yet loaded [santa.bundle.js:129:21](http://play.abstreet.org/0.3.43/santa/santa.bundle.js)
19:26:51.639 state change: error -> starting [santa.bundle.js:166:17](http://play.abstreet.org/0.3.43/santa/santa.bundle.js)
19:26:51.639 running app with assetsBaseURL: ./data, assetsAreGzipped: true [santa.bundle.js:132:25](http://play.abstreet.org/0.3.43/santa/santa.bundle.js)
19:26:51.640 state change: starting -> error [santa.bundle.js:166:17](http://play.abstreet.org/0.3.43/santa/santa.bundle.js)
19:26:51.660 Uncaught (in promise) TypeError: wasm is undefined
The network tab doesn't even show a .wasm file being loaded:
This appears to have quietly broken a week or two ago, despite there being no recent changes anywhere (S3 or Cloudfront activity generally). I invalidated the entire Cloudfront cache to be safe, but no effect.
IIUC, it looks like Cloudfront stopped returning Content-Length
headers? We try to grab that before streaming data back:
Line 121 in 4314a43
@michaelkirk if you happen to have any ideas what could've broken, I'd welcome some help! But no pressure, I'm comfortable enough in TS to figure this out now. :)
curl -v http://play.abstreet.org/0.3.43/santa/wasm_pkg/santa_bg.wasm
works fine, and has < Content-Length: 9137741
in the response headers. So since the browser's not even showing an outgoing request, something odd is happening
Ah my mistake, it shows up under XHR
in Firefox console.
Content-Length
header is missing! And Content-Encoding: gzip
is included. Compared to the s3 site:
so the change appears to be that Cloudfront started auto-gzipping things if the browser says it's OK. That's actually something useful; smaller .wasm to load! But we either need to adjust the progress bar to accept lack of content-length when gzipped, or disable this auto gzip behavior
Disabled this through the console, invalidated everything... http://play.abstreet.org/0.3.43/santa.html works again, woot!
I'll keep this issue open to do some related stuff though:
- Get https working. I did it for another S3 + Cloudfront site recently, so just have to carefully go flip the same switches
- Try auto-gzip through Cloudfront, but figure out how to send the Content-Length header of the compressed content along, or make
widgetry.ts
stop assuming it
Ha, that was quick fixing! Good work.
It's been stressing me out for a few days, but I just now had time to look into it...
https://play.abstreet.org/0.3.43/ltn.html?system/gb/bristol/maps/east.bin already works. For some unknown reason, I've just been copying http:// links everywhere. Fixing now.
I just enabled HTTPS forwarding for all subdomains of abstreet.org in Google Domains, so will update more links accordingly