Serving SQLite database files with sql.js-httpvfs broken due to gzip encoding on HEAD requests
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Bug
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- sqlite
- Bereich
- databases, infrastructure
Rechercherichtung
Keine Repository-Datei oder kein Test ist angegeben. Beginne damit, die HEAD- und Range-Anfragen gegen GitHub Pages für eine SQLite-Datei zu reproduzieren, und vergleiche anschließend die Header content-encoding und content-length; die Untersuchung ist abgeschlossen, wenn das Auslieferungsverhalten bestätigt und eine unterstützte Workaround-Lösung dokumentiert ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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!
- Vorherrschende Sprache
- Ruby
- Sterne
- 1.9k
- Forks
- 361
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus github/pages-gem
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 5/100
-
index.htmlOffen
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 5/100
-
[email protected]Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 1/100
Alle Issues in github/pages-gem
Ähnliche Issues
-
P2 testing
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
Maintainer antworten meist innerhalb von 1 Tag
-
performance
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
openSUSE/open-build-service#20338 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
DB上でコメント本文がNULLを許容しているOffenバグ
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag