[caioricciuti]

Closes #75.

DuckDB-WASM's built-in HTTP layer misreads its range probe and downloads every remote file whole (duckdb/duckdb-wasm#2228). The httpfs extension reads only the byte ranges a query needs. Thanks to @llimllib for the report and the workaround.

Measured on the query from the issue (nba.duckdb, parquet views, LIMIT 100), default settings: 27.24 MB before, 2.19 MB after, all range requests answered 206.

What changes

• Each in-browser engine (memory and OPFS) loads httpfs and sets builtin_httpfs = false on its statement connection before the next query. If httpfs cannot be loaded (offline, blocked), the built-in layer stays and works as before.
• A server that ignores Range makes httpfs fail with "Server sent back more data than expected". The statement is retried once with force_download, only when no rows were streamed yet and the SQL is a single statement, so nothing runs twice.
• Settings > Performance: "Read remote files in ranges", on by default, applies without a reload.
• Troubleshooting docs: what to check when remote reads download too much.

The single-statement check is a small scanner in rangeReads.ts, not the editor's splitter: importing that from the engine pulled the editor chunk into the startup bundle (+29 kB). index stays at 306.81 kB.

No dependency changes. httpfs is a DuckDB extension fetched at runtime from extensions.duckdb.org (about 500 kB, cached by the browser), like parquet and ducklake already are.

Verified

• lint, format, typecheck, 1213 unit tests (retry rules and the statement check included), build, site build
• Playwright 45/45 locally. The 3 new tests in e2e/rangeReads.spec.ts run on CI too: two in-test Node servers, one honouring Range, one ignoring it, plus the settings switch. New fixture e2e/fixtures/ranges.parquet (184 kB); the existing 1.1 kB one fits in a single range and never triggers the retry.

Not tried: Safari, Firefox, S3 pre-signed URLs.

[pkgfire]

PkgFire: WARN · scan details

No dependency changed. 723 packages checked.

Why

• WARN scanner_failure semgrep : The semgrep scanner did not complete (partial), so some packages have not been cleared by it.

Listed, not counted

• already_on_base: 22 packages
• new_publisher: 10 packages
• established_version: 126 packages
• provenance_lost: 4 packages
• popular_name: 2 packages