mirror of
https://github.com/tiennm99/thptqg2017.git
synced 2026-10-03 11:12:44 +00:00
tiennm99
9571fb7d55
GitHub Pages serves .sqlite3 as application/octet-stream, which mime-db marks compressible, so an un-ranged response comes back gzipped with the compressed length. sql.js-httpvfs sizes a file with a HEAD request, sees that length is unusable and refuses to open the database: Length of the file not known. It must either be supplied in the config or given by the HTTP server. Page reads were never affected. The Fetch standard requires browsers to send Accept-Encoding: identity on any request carrying a Range header, and the live site returns 206 with raw bytes to one. So the length is probed the same way and passed as fileLength, which is the escape hatch the library's own message points at. The probe reads the first 100 bytes, so it also checks the file starts with the SQLite magic and that its page size matches the request size — a host that ever compresses a ranged response now fails with a clear message rather than feeding the library the wrong bytes. The post-deploy check the docs prescribed could not have caught this: a bare `curl -sI` advertises no encoding, so it reports success whatever the host does. It is replaced, in the docs and in CI, by a ranged read that verifies the bytes.
Docs
project-overview.md— goal, scope, constraints, the datasets, historysystem-architecture.md— data flow, canonical schema, routing, how one frontend serves both exam yearsdata-pipeline.md— Excel parse quirks, per-dataset formats, overflow-sheet gotcha, expected row counts, verifying a rebuilddeployment-guide.md— GitHub Pages workflow, adding a dataset, rollback, troubleshooting