It looks like I somehow forced AppEngine to serve 200's with content, but I'm not sure how. Cached responses/304's might still be a problem for Emscripten in general.
On Thursday, May 14, 2015 at 9:02:04 AM UTC-6, Chris Keller wrote: > > Huh, well now that I've posted this, I'm not seeing the 304 Not Modified > caching problems. But I'd still like to hear your thoughts about gzip and > any other browser configuration issues that might exist. > > On Thursday, May 14, 2015 at 8:45:03 AM UTC-6, Chris Keller wrote: >> >> tl;dr Are there any known limitations or sensitivities for serving >> Emscripten-based libraries on the web? I'm specifically wondering about >> caching and gzip/other encoding issues. >> >> The long version: I'm working on a project which uses the >> Emscripten-based library texlive.js >> <https://github.com/manuels/texlive.js>. Everything works perfectly when >> testing locally with Node.js http-server, but when serving off of Google >> App Engine, I've run into problems >> <https://github.com/manuels/texlive.js/issues/26#issuecomment-99539140>. >> First, I was seeing some binary files being partially populated in the >> virtual file system. The file content was plaintext and not gzipped, but >> the file was truncated suspiciously close to the gzipped content-length. >> After disabling gzip encoding, that issue has gone away. Now I'm observing >> correct behavior the first time I use the library after purging the browser >> cache, but the second time I try to use it, the files are empty in the VFS. >> Is it possible that 304 Not Modified responses are not reading cached file >> content into the VFS? >> >> I've been able to reproduce this in both Chrome and Firefox. >> > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
