DuckDB-WASM malforms http:// URLs into https://http

[v-kessler]

What happens?

Description

When using DuckDB-WASM to read Iceberg tables from an http:// REST catalog, the data file URLs are incorrectly rewritten to https://http//..., causing the request to fail. This breaks the ability to use DuckDB-WASM with local Iceberg development environments.

4. Observe the network request in browser DevTools when DuckDB attempts to fetch Parquet data files

Expected Behavior

When the Iceberg catalog returns metadata pointing to data files at http:// URLs (e.g., from MinIO or local S3-compatible storage), DuckDB should preserve the original scheme and make requests to:

http://localhost:9000/warehouse/data/00000-0-abc123.parquet

Actual Behavior

The URL is automatically rewritten and DuckDB attempts to fetch:

https://http//localhost:9000/warehouse/data/00000-0-abc123.parquet

This results in a 404 or network error, making it impossible to read the actual table data.

Environment

• DuckDB-WASM version: ^1.31.1-dev1.0
• Browser: Microsoft Edge Version 141.0.3537.85 (Official build) (arm64)
• OS: macOS 15.6.1
• Iceberg REST Catalog: Lakekeeper
• Object Storage: AWS S3

Additional Context

• HTTPS URLs work correctly when the catalog/storage uses HTTPS

Iceberg-Specific Context

In typical local development with Iceberg:

• REST Catalog runs on http://localhost:8181
• Object Storage AWS s3

The URL malformation breaks this workflow entirely for HTTP-based development environments.

This significantly increases complexity for local Iceberg development and testing.

Impact

This prevents using DuckDB-WASM with Iceberg in:

• Local development environments (typically HTTP-only)
• Internal/private networks that may not use HTTPS
• Any HTTP-only Iceberg REST catalog + object storage setup

To Reproduce

Reproduction Steps

1. Initialize DuckDB-WASM in a browser environment
2. Configure an Iceberg catalog with HTTP endpoint:

CREATE OR REPLACE SECRET iceberg_secret_np (
        TYPE iceberg,
        TOKEN 'TOKEN' );
 ATTACH 'demo' AS demo (
          TYPE iceberg,
          SECRET iceberg_secret_np,
          ENDPOINT 'https://lakekeeper.nonprod.de/catalog'
        );

3. Query an Iceberg table:

await db.query(`
    SELECT * FROM demo.my_namespace.my_table LIMIT 10;
`);

Browser/Environment:

Microsoft Edge Version 141.0.3537.85 (Official build) (arm64)

Device:

macOS 15.6.1

DuckDB-Wasm Version:

^1.31.1-dev1.0

DuckDB-Wasm Deployment:

Vite bundled (ES modules) in Vue 3 application

Full Name:

Viktor Kessler

Affiliation:

Vakamo/Lakekeeper

[carlopi]

I am not sure this is enough for me to reproduce, I tried a few things, but it's not immediately obvious to me where this is going wrong.

I have found a problem in duckdb/duckdb-iceberg#552, that should be in any case fixed, but unsure if that's the cause.

Could you share steps to reproduce the Lakekeeper local setup?

[carlopi]

I can't reproduce locally, but then one thing that might be different is whether httpfs is explicitly autoloaded or not.

Could you try the same adding explicit LOAD httpfs; statement?
Thanks

[carlopi]

Hey @v-kessler, we did some iterations on this, in the context of https://duckdb.org/2025/12/16/iceberg-in-the-browser, could you give it another go?

[v-kessler]

@carlopi tried with "@duckdb/duckdb-wasm": "^1.32.1-dev1.0", but same pattern
HTTP => https://http//localhost:8181/catalog/v1/config?warehouse=r2 - WRONG
HTTPS => https://lakekeeper.nonprod.de/catalog/v1/config?warehouse=r2 CORRECT

let me know we an chat , maybe I have some issue on my end

[v-kessler]

@carlopi it did work with FORCE INSTALL iceberg FROM core_nightly; no I see proper http://localhost:8181/catalog/v1/config?warehouse=r2 but the nightly is not loading proper yet https://nightly-extensions.duckdb.org/v1.3.2/wasm_eh/iceberg.duckdb_extension.wasm

when the nighly will be available in GA / or in INSTALL ICEBERG;?