Serving SQLite database files with sql.js-httpvfs broken due to gzip encoding on HEAD requests
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- sqlite
- Domain
- databases, infrastructure
Research direction
No repository file or test is identified. Start by reproducing the HEAD and Range requests against GitHub Pages for a SQLite file, then compare the content-encoding and content-length headers; the investigation is done when the serving behavior is confirmed and a supported workaround is documented.
Written by the indexing model from the issue text.
Description
I have been using GitHub Pages to serve SQLite database files for a client-side app with sql.js-httpvfs, which requires HTTP Range requests to read parts of the database file.
Until recently, this setup worked correctly. However, now the sql.js-httpvfs worker throws an error:
Length of the file not known. It must either be supplied in the config or given by the HTTP server.
Upon inspecting the HTTP response headers, I see that HEAD requests respond with content-encoding: gzip. According to sql.js-httpvfs, this breaks range requests because the server returns compressed data on HEAD but serves uncompressed data on range requests, making the byte length calculation incorrect.
Example response headers from a HEAD request:
content-encoding: gzip accept-ranges: bytes content-length: 1288
This behavior causes sql.js-httpvfs to fail when trying to read the file size and ranges properly.
Could you please confirm if there has been a recent change in how GitHub Pages serves static files or handles gzip encoding on HEAD and Range requests? Is there a recommended workaround to properly serve files that need range requests without gzip interfering?
Thank you very much for your help!
- Dominant language
- Ruby
- Stars
- 1.9k
- Forks
- 361
- PR merge metrics
- No merged PRs in 30d
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/pages-gem
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 5/100
-
index.htmlOpen
Difficulty 5/5 Over a week Newbie friendliness 5/100
-
[email protected]Open
Difficulty 1/5 Under an hour Newbie friendliness 1/100
All issues in github/pages-gem
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
FreeCAD/homebrew-freecad#870 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
security
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
OSCON 2016Opencontent
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
rubyevents/rubyevents#2148 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
we-promise/sure#3838 · 2 comments ·
Maintainers usually reply within 1 day