Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Serving SQLite database files with sql.js-httpvfs broken due to gzip encoding on HEAD requests

未关闭
#952 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
停滞
技术栈
sqlite

调研方向

未识别出 repository 文件或测试。首先针对一个 SQLite 文件重现向 GitHub Pages 发出的 HEAD 和 Range 请求,然后比较 content-encoding 和 content-length 标头;当确认提供服务的行为并记录受支持的变通方案后,调查即告完成。

由索引模型根据 Issue 内容生成。

描述

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!

主要语言
Ruby
星标
1.9k
派生
361
PR 合并指标
30 天内没有已合并 PR

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

github/pages-gem 的其他 Issue

查看 github/pages-gem 的全部 Issue

相似的 Issue

更多 Ruby Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。