Bug: Web GUI file preview shows "file resource service unavailable" on Chromium <= 125 — protocolOf() relies on WHATWG URL host parsing for a non-special scheme

[Jack-lss]

Web GUI: every file preview fails with "file resource service unavailable" on Chromium ≤ 125 (protocolOf() relies on WHATWG URL host parsing for a non-special scheme)

Summary

On Chromium browsers before 126 (e.g. Chrome 125), every file preview in the Web GUI — the sidebar Files tab, chat file links, and deliverables rows — renders “文件资源服务不可用。” (EN: "The file resource service is unavailable."). No /api/workspaceFiles/* requests are issued. The Host service, the client boot graph, and all client bundles are healthy; the failure is a client-side address-parsing incompatibility.

Root cause

@deepseek-ai/dsh-client-resources derives the resource protocol key from new URL(...).hostname:

function protocolOf(address) {
	let parsed;
	try {
		parsed = new URL(address);
	} catch {
		return;
	}
	if (parsed.protocol !== `dsh-resource:`) return void 0;
	return parsed.hostname === "" ? void 0 : parsed.hostname.toLowerCase();
}

Whether a //authority of a non-special scheme (dsh-resource:) is parsed as a host depends on the 2024 URL Standard change (whatwg/url#731, "Allow non-special schemes to have hosts"), shipped in Chrome/Edge 126:

Browser	new URL("dsh-resource://file/session/x/C:/a.txt").hostname	Behavior
Chromium ≥ 126 (also current Node.js)	"file"	protocol key "file" → the workspace-files provider is found → preview works
Chromium ≤ 125	"" (empty)	protocolOf returns undefined → the ResourceRegistry records the address as status: "none" → the document preview renders t("resourceUnavailable") and never issues a workspaceFiles.stat call

Every preview surface shares this registry (sidebar Files tab, chat file links, deliverables), so on affected browsers the failure is global, deterministic across reloads, and invisible server-side (the Host never receives a request).

Reproduction

1. Serve the Web GUI from any working setup (server version is irrelevant; verified on 0.1.5-rc.1).
2. Open the GUI in Chromium ≤ 125, e.g. npx @puppeteer/browsers install chrome@125.0.6422.60.
3. Open any text file (sidebar Files tab or a chat file link).

Observed: “文件资源服务不可用。”; DevTools shows zero /api/workspaceFiles calls. In the same browser's console:

new URL("dsh-resource://file/session/x/C:/a.txt").hostname // → "" (Chrome 125)
new URL("dsh-resource://file/session/x/C:/a.txt").hostname // → "file" (Chrome ≥ 126 / Node)

The same server/session/account renders the file correctly on Chromium ≥ 126.

Suggested fix

Do not derive the protocol key from WHATWG hostname parsing; read the authority from the address string directly. One-file change in @deepseek-ai/dsh-client-resources:

function protocolOf(address) {
	if (typeof address !== "string") return void 0;
	const authorityPrefix = "dsh-resource://";
	if (!address.startsWith(authorityPrefix)) return void 0;
	const rest = address.slice(authorityPrefix.length);
	const end = rest.search(/[/?#]/);
	const host = end === -1 ? rest : rest.slice(0, end);
	return host === "" ? void 0 : host.toLowerCase();
}

Behavior-identical on modern engines, fixes ≤ 125. parseFileAddress (string slicing) is unaffected; we audited all shipped client bundles for new URL(...).hostname on dsh-resource: addresses — protocolOf is the only occurrence.

Verified

Patched a 0.1.5-rc.1 deployment with the snippet above and drove the real GUI headlessly:

• Chrome 125.0.6422.60: before → “文件资源服务不可用。” for every preview surface; after → text/code/markdown previews render normally (workspaceFiles.stat + read return 200).
• Edge 148: no regression (renders before and after).

Environment

• dsh 0.1.5-rc.1 (npx @deepseek-ai/dsh), Windows 10 x64
• Broken: Chrome 125.0.6422.60 · Working: Edge 148, any Chromium ≥ 126

---

备注（中文）：这是 0.1.5-rc.1 新增的可扩展文档预览功能在老 Chromium 上的全局失效；根因与修复如上，补丁已在本地部署验证。

[Mide69]

Checked this against current upstream master and it is still exactly there. packages/client/resources/src/client/resources.ts still has:

export function protocolOf(address: string): string | undefined {
let parsed: URL
try {
parsed = new URL(address)
} catch {
return undefined
}
if (parsed.protocol !== ${RESOURCE_SCHEME}:) return undefined
return parsed.hostname === '' ? undefined : parsed.hostname.toLowerCase()
}

with RESOURCE_SCHEME = 'dsh-resource', so the whole feature does depend on WHATWG host parsing for a non-special scheme, exactly as you traced. There is even a comment directly above the hostname read, "A non-special scheme's host is opaque to the URL parser and keeps its case," which was true assuming the 2024 URL Standard behavior (whatwg/url#731) is already shipped everywhere. Chrome/Edge only shipped that at 126, so the comment states the post-126 behavior as if it were universal, which is the same gap your report identifies from the browser side.

Your fix avoids the WHATWG parser entirely for the host extraction, which sidesteps the version dependency rather than working around one engine's timeline. Good bug to catch since it fails completely silently client-side, no request ever reaches the Host, so there is nothing in server logs to point at the browser as the cause.

[PerryLink]

核实结论:机制成立,但版本分界写错了——不是 Chromium 126,是 130;与 #6437 是同根因族.

1. protocolOf 依赖点属实:packages/client/resources/src/client/resources.ts:56-68,第 67 行 hostname 为空返回 undefined;RESOURCE_SCHEME='dsh-resource'(:46),唯一调用点 :120. master(c291e79)原样存在,与 Bug: Web GUI file preview shows "file resource service unavailable" on Chromium <= 125 — protocolOf() relies on WHATWG URL host parsing for a non-special scheme #6217 评论1(Mide69)核对一致. 失败链属实:protocol undefined → 记录 idle('none')(resources.ts:122)→ 渲染「文件资源服务不可用.」(ui-sidebar-documentpreview/src/client/locales.ts:21,TextPreview.tsx:84/179),全程不发 workspaceFiles 请求,宿主侧无日志——静默失效成立.
2. 版本分界不成立:该行为源自 WHATWG URL 标准 2024 变更(非特殊 scheme 不再按 opaque path 解析),Chromium 在 Chrome/Edge 130 默认启用(chromestatus 5201116810182656;appui#1089 实测 v130+ 行为变化). 故 126–129 同样失败;[Bug] dsh-client-resources 的 protocolOf 依赖 new URL().hostname，Edge 129 下文件预览显示“文件资源服务不可用” #6437 的 Edge 129 实测恰是反例,与我方 [Bug] dsh-client-resources 的 protocolOf 依赖 new URL().hostname，Edge 129 下文件预览显示“文件资源服务不可用” #6437 已核结论同因;本线程的 Chrome 125(坏)与 Edge 148(好)均与 130 分界相容. 原帖引的 whatwg/url#731 现已 410 Gone,无法按号核对,规范本身真实.
3. 修复方向成立,一处修正:原帖 startsWith 写法大小写敏感,会打破既有单测(resources.client.spec.ts:98 大写 scheme 应得 'file');建议采用 [Bug] dsh-client-resources 的 protocolOf 依赖 new URL().hostname，Edge 129 下文件预览显示“文件资源服务不可用” #6437 的正则 /^dsh-resource://([^/?#]+)/i. 附带:tab-registry.ts:189-191 的 pathOf 用 new URL().pathname 解析同类地址,是同族第二处,建议一并字符串化.

[Mide69]

@PerryLink good catches, both of them.

On the version boundary: fair to flag, I only checked that the dependency exists, not exactly which Chromium release closed it, so I cannot confirm 130 over 126 myself without checking chromestatus directly. Either way it does not change the fix, since removing the URL-parser dependency entirely means the exact boundary version stops mattering.

On the case-sensitivity concern: good thing to check, and it turns out already handled. My actual pushed fix matches the dsh-resource:// prefix case-insensitively, specifically because of that same existing test (DSH-RESOURCE://File/... -> 'file'), not the OP's original case-sensitive startsWith snippet. So resources.client.spec.ts:98 still passes as is.

On pathOf in tab-registry.ts: real find, thank you. Checked it and it is the same anti-pattern, new URL(address).pathname excludes the authority from the path only when the engine assigns dsh-resource:// a host, so path-only globs (*.png, *.md, ...) silently never matched a dsh-resource:// address on the same affected engines. Fixed and pushed on the same branch, generalized to any scheme://authority address since pathOf's own contract already covers more than just dsh-resource:.

Branch, now covers both: https://github.com/Mide69/deepseek-harness/tree/fix/resource-protocol-legacy-url-hosts

[totoanew]

补充一个实测反馈：旧版 Chrome 可能导致 DSH Web UI 文件预览提示“文件资源服务不可用”。

我在工作电脑上使用 DSH Web UI 时，页面上能看到生成的文件入口，但点击预览会出现上述报错。原先使用的是大约 2024 年 8 月的旧版 Chrome，具体版本号未记录；升级到 Chrome 143 后，文件预览恢复正常。

遇到相同问题的朋友，可以先检查浏览器版本，用较新版本的浏览器打开同一个 DSH 页面、预览同一个文件作对照，不要仅凭这个报错就认定后端文件服务不可用。

注意：Chrome 143 是我实际验证可用的版本，并不代表最低支持版本是 143，也不能据此认定所有低于 143 的版本都会出问题。这里仅提供我这次环境中的实测结果，未单独验证底层技术原因。

建议维护者在排障文档中补充浏览器兼容性提示，或改进相关报错信息，帮助用户减少无效排查。

[heimixieb]

Version sweep update: still unfixed in 0.1.7-alpha.2. Read the shipped @deepseek-ai/dsh-client-resources/lib/client.js from a fresh npx install of 0.1.7-alpha.2 today: protocolOf is still the new URL(...).hostname variant, byte-for-byte the same logic. #7412's sweep table can add that row (0.1.5-alpha.1 … 0.1.6-alpha.2 → 0.1.7-alpha.2: 未修).

A fresh 0.1.7-alpha.2 user case reproduces exactly the failure this thread describes (file tree fine; every preview — sidebar, chat links — shows 「文件资源服务不可用」; zero console errors; deterministic across hard reloads; Host never sees a request). By elimination the only mechanism left inside ResourceRegistry is protocolOf returning undefined for well-formed addresses — the reasoning chain and the same-symptom thread #7514's "provider registered but none" paradox are reconciled in my comment there.

Applied the fix locally in the shape agreed in this thread (case-insensitive scheme match + string authority extraction, userinfo stripped — 16/16 equivalence cases incl. the DSH-RESOURCE://File/... one pinned by resources.client.spec.ts:98), plus the pathOf anti-pattern in ui-sidebar-right's tab-registry that @Mide69 flagged above. Every preview recovered in the affected browser.

One more vote for folding in the amplifier fix while touching this: const canRead = meta.status !== 'none' in TextPreview gates content reads on metadata availability, so this single address-parsing miss becomes a total preview outage. Content reads go through remote.workspaceFiles and already carry typed failures + retry; decoupling them degrades the bug to "auto-refresh off" and is a one-line change. We shipped that locally too and it is what made the symptom disappear before the root-cause patch went in — worth keeping as defense-in-depth even after protocolOf is fixed.