dsh-v0.1.2-alpha.1: WorkerTunnel rejects absolute URLs under file:// null origin

[Jstn-1g]

Summary

On exact dsh-v0.1.2-alpha.1 (cd5ef8148158c3a752a658978873241fdf8e2bbc), WorkerTunnel.fetch() throws TypeError: Invalid URL under a file:// page whose location.origin is "null", even when its input is already an absolute http://dsh.internal/... URL. The throw happens before postMessage, so no IPC request frame reaches TunnelServer.

This report is narrowly about reusing the exact-alpha WorkerTunnel under null origin. It is not a claim that every Desktop shell or every IPC design is broken.

Exact reproduction

• DSH commit/version: cd5ef8148158c3a752a658978873241fdf8e2bbc / 0.1.2-alpha.1
• Reproduced on Node 22.22.2 and Node 24.19.0 locally; clean pinned workflow uses Node 24.12.0
• DSH Live Voice proof commit: 6e97573c2d5d7769ab7a35ae087ac3eb6e8083e6

Object.defineProperty(globalThis, 'location', {
  configurable: true,
  value: {
    href: 'file:///synthetic/dsh/index.html',
    protocol: 'file:',
    origin: 'null',
    hostname: '',
    search: '',
  },
})

const sent: unknown[] = []
const tunnel = new WorkerTunnel({
  addEventListener: () => {},
  postMessage: (frame: unknown) => { sent.push(frame) },
} as unknown as Worker)

await tunnel.fetch(
  new URL('http://dsh.internal/api/ipcVoiceProbe/begin'),
  { method: 'POST', body: '{}' },
)

Expected: the already-absolute URL is serialized into one req frame, or the carrier exposes a documented supported normalization step.

Actual: TypeError: Invalid URL; sent remains [].

Source-level mismatch

The Client Connection RPC deliberately falls back to http://dsh.internal when the page origin is null:

• packages/client/connection/src/client/rpc.ts

WorkerTunnel.fetch() then resolves that already-absolute input again against globalThis.location.origin:

• packages/experimental/webworker-runtime/src/client/client.ts

Because the base is the string "null", URL construction throws before the frame is posted.

Independent proof and boundaries

A test-only bounded adapter that normalizes the absolute URL can traverse the exact alpha's real Typert generator, generated strict Host/Remote descriptors, Client/Host Connection and Gateway seams, TunnelServer, and SessionStore.fork() over a structured-clone MessageChannel:

• Reviewed implementation PR
• Fresh frozen-lockfile workflow run

The clean run passed 6/6 and emitted publishable: true for this synthetic IPC-equivalent claim. It also explicitly records credentialBackedProvider:false, physicalAudio:false, electron:false, tauri:false, packagedDesktop:false, and officialSeamConfirmation:false.

The adapter is not a drop-in WorkerTunnel: it has proof-specific body, queue, error, abort, and lifecycle policy. No production DSH Live Voice carrier was changed.

I searched current discussions before posting. The closest items I found were #3118 (Electron file:// + IPC carrier work) and #5063 (embedded authentication); neither describes this pre-frame null-origin URL failure.

Maintainer clarification requested

1. Should WorkerTunnel.fetch() preserve an already-absolute URL, or use the same internal-base fallback as Client Connection under null origin?
2. Is URL normalization expected to be shell-owned instead?
3. For plugins needing bounded bidirectional data, is generated Remote/Gateway composition an intended public seam, or should we wait for another transport contract?

Served-Web development can continue safely while this is clarified. We will not claim packaged Desktop support or an official carrier seam from the synthetic proof.

[Jstn-1g]

I prepared the smallest upstream patch for this exact failure rather than adding a Live Voice production workaround:

• reviewable comparison: master...Jstn-1g:deepseek-harness:fix/webworker-null-origin-url
• exact commit: Jstn-1g@16970b2

WorkerTunnel.fetch() now uses the same opaque-origin fallback already used by dsh-client-connection: preserve the real page origin when available, otherwise resolve against http://dsh.internal. The regression test covers both the Connection-provided absolute URL and the relative /__boot__ request under location.origin === "null".

Verification on exact dsh-v0.1.2-alpha.1 / cd5ef814:

• failing before: ERR_INVALID_URL, input http://dsh.internal/api/session.list, base null;
• focused tunnel test: 29/29;
• complete WebWorker-runtime suite: 29 files / 512 tests;
• package TypeScript build and package bundle build passed;
• repository pre-commit staged lint/whitespace/manifest checks passed;
• repository pre-push full Host build and Client contract typecheck passed; and
• independent exact-diff review found no remaining issue.

External pull requests are currently disabled, so this is a cherry-pickable comparison for maintainer review. The claim remains narrow: URL resolution now works for an opaque/null-origin page. This does not prove packaged Desktop/Electron, authentication, a production Live Voice carrier, or an official plugin integration seam.

[argszero]

Verified both refs against the exact alpha tree (cd5ef81) — your diagnosis is precise, and this is a two-line fix.

Confirmed 1 — the asymmetry. Client Connection has a null-origin guard: resolveBase() (packages/client/connection/src/client/rpc.ts:103-108) returns INTERNAL_BASE when location.origin is undefined or 'null'. WorkerTunnel.fetch() (packages/experimental/webworker-runtime/src/client/client.ts:194-205) re-resolves unconditionally: url: new URL(input, globalThis.location.origin).toString() (:200). Under file://, location.origin is the string "null", so new URL('http://dsh.internal/…', 'null') throws TypeError: Invalid URL before postMessage — exactly your repro.

Confirmed 2 — the frame never leaves. The new URL is evaluated inline while building frame (:199-206); the throw aborts fetch before any postMessage. Your sent === [] observation is the necessary consequence.

Answer to Q1 (maintainer decision): preserve an already-absolute input, don't re-resolve. Two concrete shapes, both minimal:

• Guard the resolution: only apply new URL(input, base) when the input is not already absolute — e.g. keep the current behavior for relative inputs (which still need the INTERNAL_BASE fallback under null origin, mirroring resolveBase()), and serialize an absolute input as-is.
• Or, cleaner for consistency: extract/export the same resolveBase() null-origin fallback from client/connection and reuse it here, so the two carriers can't drift again.

Q2/Q3 context. URL normalization being "shell-owned" would leave every embedded-script author re-implementing a guard the host already ships in resolveBase() — the asymmetry is an accident of two carriers evolving independently, not a deliberate ownership split. The INTERNAL_BASE constant (packages/client/connection, http://dsh.internal) is already the de-facto null-origin contract, so reusing it in WorkerTunnel is the least-surprise option. On Q3, the generated Remote/Gateway composition is documented for served-web; for a null-origin embed, the safe statement today is: use the tunnel + a host route rather than assuming an official public seam.

Your patch direction (in the fix/webworker-null-origin-url comparison) matches the first shape. This is the same family as the "correct mechanism exists, wiring missing" pattern — resolveBase() already solved null-origin once; the second carrier never adopted it.

[liyangbing]

这个复现把“null origin URL 解析失败”和“WebView/桌面认证或 IPC 权限问题”正确分开了；这对集成方很重要：postMessage 尚未发生时，不能把它归因于 TunnelServer、CORS 或凭据。

我维护的独立 DeepSeek Harness 社区手册也采用同样的边界记录方式：official project identity and desktop-shell boundary。对该 alpha revision，建议把验收矩阵固定为：

• served origin：relative URL 与 absolute URL 各跑一次；
• file:// / location.origin === null：确认 absolute input 能产生单个 req frame，relative input 使用明确的 internal base；
• frame count：失败时确认 postMessage 为 0，修复后确认只发 1 个 frame；
• 分开记录 URL normalization、auth、IPC allowlist、Host routing，不能用一个“Desktop works”结论覆盖它们。

若维护者合入比较中的两行修复，最好保留 exact commit cd5ef81 的回归测试，并在下一版本注明“opaque-origin URL resolution fixed”；这不会自动证明 Electron/Tauri、生产 carrier 或官方插件 seam 已受支持。