Serving SQLite database files with sql.js-httpvfs broken due to gzip encoding on HEAD requests
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 25/100
- Type d'issue
- Bug
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- sqlite
- Domaine
- databases, infrastructure
Piste de recherche
Aucun fichier du dépôt ni aucun test n’est identifié. Commencez par reproduire les requêtes HEAD et Range vers GitHub Pages pour un fichier SQLite, puis comparez les en-têtes content-encoding et content-length ; l’investigation est terminée lorsque le comportement de diffusion est confirmé et qu’une solution de contournement prise en charge est documentée.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
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!
- Langage dominant
- Ruby
- Étoiles
- 1.9k
- Forks
- 361
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de github/pages-gem
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
Error when building docker imageOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 5/100
-
index.htmlOuverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 5/100
-
[email protected]Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 1/100
Toutes les issues de github/pages-gem
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
solana-foundation/pay-kit#341 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 95/100
Les mainteneurs répondent en général sous 1 jour
-
Sign and read plain-text assetsOuverteenhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour
-
Cask still fails to install: `depends_on macos: :catalina` is now disabled (regression after #58)Ouverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100