a-b-street/abstreet

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:
Screenshot from 2023-04-20 19-31-05

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:

let reader = response.body.getReader();

@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.
Screenshot from 2023-04-20 19-38-16
Content-Length header is missing! And Content-Encoding: gzip is included. Compared to the s3 site:
Screenshot from 2023-04-20 19-39-15

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

Screenshot from 2023-04-20 19-44-17
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