Repository navigation
Connection strings using http:// or https:// are rejected as an unsupported driver #6
Description
Description
Importing an http:// or https:// connection string (e.g. for a self-hosted sqld server with a namespace path) fails with an "Unsupported database driver: http" style error. The string never reaches the plugin.
Steps to reproduce
- New connection → libSQL driver
- Paste
http://localhost:8080/dev/example/into the connection-string field - The import is rejected before any plugin RPC is sent
Root cause
.tabularium declares connection_uri: true but its connection_uri_schemes list only contained turso, wss, ws, file. The host's connection-string parser resolves the protocol against that registry (driver id libsql and the example's scheme are implicit), so http/https had no owning driver and the parse failed up front.
The plugin itself already handled these URLs (URL_SCHEMES in src/client.rs includes http:///https://, and normalize_remote_url passes them through unchanged), so the manifest declaration was the only gap.
Expected
http://localhost:8080/dev/example/ is accepted, arrives verbatim via connection_uri, and queries are posted to the namespaced endpoint.
Fix
Declare http and https in connection_uri_schemes, document the case in the README, and add regression tests for scheme/path preservation. Released as 1.0.1.
Verified end-to-end with a local listener on port 8080: the plugin POSTs to /dev/example/v2/pipeline for the connection string above.
Activity
jonaspm commentedon Sep 15, 2026
Manual testing surfaced a second failure mode with the same string, also fixed on the PR branch: when the host sends params decomposed (
host: "192.0.2.10",port: 8080,database: "dev/example") instead of the verbatim URI, the remote branch ignoreddatabase, builthttp://192.0.2.10:8080and posted to/v2/pipeline. sqld then resolved the namespace from the Host header (the first octet of the IP) and returned a404 Namespace ... doesn't exist. The database path is now kept as a URL prefix when it contains/(Turso names cannot), verified end-to-end against a local listener:POST /dev/example/v2/pipeline.jonaspm commentedon Sep 15, 2026
Third root cause, also fixed on the PR branch: sqld resolves the namespace from the
x-namespaceheader, not from the URL path. Against the actual server (sqld 0.24.33) the plugin was already posting to the namespaced URL, but the server ignored the path and fell back to the Host header (the first octet of the IP) →404 Namespace ... doesn't exist. Raw probes: namespaced path +x-namespace: example→ 200; same without the header → 404. The plugin now derives the namespace from the URL path (dev/example→example) and sends the header; plain Turso hosts (database in the hostname) send none. Verified end-to-end with the params the host sent:test_connectionOK and metadata queries return real data.