fix(extensions): fetch http marketplaces with http client

[tt-a1i]

What this PR does

Uses the Node HTTP client for http:// extension marketplace sources and the HTTPS client for https:// sources.

The existing timeout, body-size limit, JSON parsing, and null-on-error behavior stay the same.

Why it's needed

loadMarketplaceConfigFromSource accepts direct http://.../marketplace.json URLs, but the shared fetch helper always called https.get. Node rejects that client/protocol mismatch before making the request, so valid local or internal HTTP marketplace sources could not load.

Reviewer Test Plan

How to verify

Review fetchUrl and the marketplace tests. The http:// case should go through http.get; HTTPS and GitHub-backed sources should continue to use https.get.

Run:

npx vitest run packages/core/src/extension/marketplace.test.ts
npx eslint packages/core/src/extension/marketplace.ts packages/core/src/extension/marketplace.test.ts

Evidence (Before & After)

Before: http://.../marketplace.json failed with Protocol "http:" not supported. Expected "https:".

After: HTTP marketplace URLs are fetched with the HTTP client, while HTTPS marketplace URLs keep the previous HTTPS path.

Tested on

OS	Status
macOS	tested
Windows	covered by CI
Linux	covered by CI

Environment (optional)

Local Node/npm workspace tests.

Risk & Scope

• Main risk or tradeoff: direct marketplace fetching now branches on URL protocol; unsupported protocols still fail through URL/client handling.
• Not validated / out of scope: adding support for protocols other than HTTP and HTTPS.
• Breaking changes / migration notes: none.

Linked Issues

Fixes #5451

AI Assistance Disclosure

I used Codex to review the changes, sanity-check the implementation against existing patterns, and help spot potential edge cases.

中文说明

这个 PR 做了什么

让 http:// 扩展 marketplace 源使用 Node 的 HTTP client，让 https:// 源继续使用 HTTPS client。

原有的超时、响应体大小限制、JSON 解析和出错返回 null 的行为不变。

为什么需要

loadMarketplaceConfigFromSource 支持直接传入 http://.../marketplace.json，但共享 fetch helper 之前总是调用 https.get。Node 会在发请求前拒绝这种 protocol/client 不匹配，因此本地或内网 HTTP marketplace 源无法加载。

Reviewer Test Plan

How to verify

检查 fetchUrl 和 marketplace 测试：http:// 用例应走 http.get，HTTPS 和 GitHub 源应继续走 https.get。

Evidence (Before & After)

修复前：http://.../marketplace.json 会报 Protocol "http:" not supported. Expected "https:"。

修复后：HTTP marketplace URL 使用 HTTP client；HTTPS URL 保持原来的 HTTPS 路径。

Tested on

本地跑过相关 Node/npm 测试；Windows 和 Linux 由 CI 覆盖。

Risk & Scope

改动只影响直接 marketplace URL 的协议选择。不新增 HTTP/HTTPS 以外的协议支持，也没有破坏性变更。

[wenshao]

No issues found. The protocol-based client selection in fetchUrl is correct — new URL(url).protocol normalizes case, the two internal GitHub callers stay on https, and a malformed URL throws ERR_INVALID_URL exactly as the previous https.get(url) did (no new failure path). The added test genuinely covers the http:// route (it fails against the pre-fix https.get implementation). Downgraded from Approve to Comment: CI still running. — claude-opus-4-8[1m] via Qwen Code /qreview

[wenshao]

@qwen-code /triage

[qwen-code-ci-bot]

Hi @tt-a1i — thanks for the fix! The change itself looks focused and reasonable, but the PR body doesn't follow our pull request template. Several required sections are missing:

• What this PR does / Why it's needed — there's a "Summary" but no separate motivation section
• Reviewer Test Plan (How to verify, Evidence Before & After, Tested on) — "Test Plan" lists commands but doesn't describe what a reviewer should confirm or show before/after
• Risk & Scope — not present
• Linked Issues — not present (Fixes #5451 is in the Summary, but the section is expected for traceability)
• 中文说明 — not present

Could you restructure the PR body to match the template? It helps reviewers (and our automated triage) evaluate the change consistently. Happy to re-run triage once updated.

中文说明

@tt-a1i 你好——感谢这个修复！改动本身很聚焦且合理，但 PR 正文没有遵循我们的 PR 模板，缺少几个必填章节：

• What this PR does / Why it's needed — 有 "Summary" 但没有单独的动机说明
• Reviewer Test Plan（验证方法、改动前后证据、测试平台）— "Test Plan" 列出了命令，但没有描述审查者应确认什么或展示前后对比
• Risk & Scope — 缺失
• Linked Issues — 缺失（Fixes #5451 写在 Summary 里，但需要单独章节以便追踪）
• 中文说明 — 缺失

请按模板重新组织 PR 正文，更新后我们会重新跑 triage。谢谢！

— Qwen Code · qwen3.7-max

[wenshao]

✅ Local end-to-end verification (real HTTP/HTTPS servers, tmux)

Verified the fix against a real local HTTP server and a real HTTPS server (self-signed cert, trusted via NODE_EXTRA_CA_CERTS) — no vitest mocks. The harness drives the real built ExtensionManager.addSource / loadSource — the exact object the qwen extensions sources add|update commands construct via getExtensionManager(). Both builds were compiled to real packages/core/dist:

• BASE = merge-base 61dcf865 (pre-fix, https.get)
• PR = head d98e6289 (protocol-aware client.get)

Root cause confirmed

On BASE, feeding an http://…/marketplace.json source into addSource() throws Node's
Protocol "http:" not supported. Expected "https:" from https.get(), so HTTP marketplace
sources can never load. This matches the issue exactly.

A/B result

Probe (real socket)	BASE 61dcf865	PR d98e6289
addSource('http://…/marketplace.json')	❌ throws Protocol "http:" not supported	✅ Added marketplace "http-test-marketplace"
loadSource('http://…') → plugin listing	❌ throws (same)	✅ 2 plugins: [alpha, beta]
addSource('https://…') — no-regression	✅ Added	✅ Added

========== BASE (61dcf865) ==========
  ✅ PASS  [HTTP addSource]                 THREW-> Protocol "http:" not supported. Expected "https:"
  ✅ PASS  [HTTP loadSource plugins]        THREW-> Protocol "http:" not supported. Expected "https:"
  ✅ PASS  [HTTPS addSource (no-regression)] OK -> Added marketplace "http-test-marketplace"
========== PR (d98e6289) ==========
  ✅ PASS  [HTTP addSource]                 OK -> Added marketplace "http-test-marketplace" (type=http)
  ✅ PASS  [HTTP loadSource plugins]        OK -> 2 plugins: [alpha, beta]
  ✅ PASS  [HTTPS addSource (no-regression)] OK -> Added marketplace "http-test-marketplace"

Result deterministic across repeated runs (ports randomized each run), process exit 0.

Unit test + static checks

• vitest run packages/core/src/extension/marketplace.test.ts → 27/27 pass on PR.
• Revert-proof A/B: restoring only marketplace.ts to the merge-base (https.get) while keeping the new test makes "fetches direct HTTP marketplace JSON with the HTTP client" fail — the added test genuinely pins protocol selection.
• ESLint + Prettier clean on both changed files; tsc --noEmit reports zero errors in the PR's files (the lone custom-provider.test.ts TS2339 is pre-existing on main, unrelated to this PR).

Notes

• new URL(url).protocol lower-cases the scheme, so HTTP:// is handled too; the two GitHub callers (api.github.com, raw.githubusercontent.com) stay on https.
• The new URL(url) now sits outside the returned Promise, but a malformed http://… string throws ERR_INVALID_URL in both old (https.get → internal new URL) and new code — confirmed empirically across http://, http://:::invalid, http://[bad, http:// space. No new failure path.

Verdict: LGTM — the fix works end-to-end with a real server and introduces no HTTPS regression.

🇨🇳 中文版本（点击展开）

✅ 本地端到端验证（真实 HTTP/HTTPS 服务器，tmux）

使用真实的本地 HTTP 服务器和真实的 HTTPS 服务器（自签名证书，通过 NODE_EXTRA_CA_CERTS 信任）验证，未使用 vitest mock。测试驱动的是真实编译产物中的 ExtensionManager.addSource / loadSource——也就是 qwen extensions sources add|update 命令通过 getExtensionManager() 实际构造的同一个对象。两个版本都编译为真实的 packages/core/dist：

• BASE = merge-base 61dcf865（修复前，https.get）
• PR = head d98e6289（按协议选择 client.get）

根因确认

在 BASE 上，把 http://…/marketplace.json 源传入 addSource() 会从 https.get() 抛出 Node 的
Protocol "http:" not supported. Expected "https:"，因此 HTTP 市场源永远无法加载，与 issue 描述一致。

A/B 结果

探针（真实 socket）	BASE 61dcf865	PR d98e6289
addSource('http://…/marketplace.json')	❌ 抛出 Protocol "http:" not supported	✅ Added marketplace "http-test-marketplace"
loadSource('http://…') → 插件列表	❌ 抛出（同上）	✅ 2 plugins: [alpha, beta]
addSource('https://…') —— 回归检查	✅ 成功	✅ 成功

多次重复运行结果稳定（每次随机端口），进程退出码为 0。

单元测试 + 静态检查

• vitest run packages/core/src/extension/marketplace.test.ts → PR 上 27/27 通过。
• 反向验证 A/B：仅把 marketplace.ts 回退到 merge-base（https.get）、保留新测试，"fetches direct HTTP marketplace JSON with the HTTP client" 用例会失败——说明新增测试确实锁定了协议选择逻辑。
• 两个改动文件的 ESLint + Prettier 均通过；tsc --noEmit 在 PR 改动文件中零报错（唯一的 custom-provider.test.ts TS2339 是 main 上已存在的问题，与本 PR 无关）。

补充说明

• new URL(url).protocol 会将协议转为小写，因此 HTTP:// 同样能正确处理；两个 GitHub 调用方（api.github.com、raw.githubusercontent.com）仍走 https。
• 现在 new URL(url) 移到了返回的 Promise 之外，但对于非法的 http://… 字符串，新旧代码都会抛出 ERR_INVALID_URL（旧代码经由 https.get 内部的 new URL）——已用 http://、http://:::invalid、http://[bad、http:// space 实测确认，未引入新的失败路径。

结论：LGTM —— 修复在真实服务器下端到端有效，且不会造成 HTTPS 回归。

[tt-a1i]

updated the PR body to match the template.

[wenshao]

@qwen-code /triage

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓ — all required sections present, bilingual description included.

On direction: this fixes a genuine bug. loadMarketplaceConfigFromSource advertises support for http:// URLs in its docstring and code path, but the shared fetchUrl helper always called https.get, making HTTP marketplace sources impossible to load. Real use case — local dev servers, internal registries, CI environments serving marketplace JSON over plain HTTP.

On approach: the scope is minimal and exactly right. Three lines of production code: import http, select client by protocol, use it. No scope creep, no drive-by refactors. The new URL(url).protocol call happens before the Promise, which is correct — a malformed URL would have thrown inside https.get anyway, so no new failure surface. The docstring update from https:// to http(s):// is a nice touch.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓ — 所有必填章节齐全，含双语描述。

方向：修复了一个真实 bug。loadMarketplaceConfigFromSource 的文档和代码路径声称支持 http:// URL，但共享的 fetchUrl 始终调用 https.get，导致 HTTP marketplace 源完全不可用。本地开发服务器、内网 registry、CI 环境中通过纯 HTTP 提供 marketplace JSON 都是合理场景。

方案：范围极小且恰到好处。三行生产代码：导入 http、按协议选择 client、使用它。无范围蔓延、无顺手重构。new URL(url).protocol 放在 Promise 之前是正确的——畸形 URL 在旧代码的 https.get 内部同样会抛出，没有引入新的失败面。文档从 https:// 更新为 http(s):// 也是恰当的补充。

进入代码审查 🔍

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

Code Review

Before reading the diff, my independent proposal was identical: import node:http, check new URL(url).protocol, branch between http and https. The PR matches this exactly.

The implementation is clean and correct:

• fetchUrl is shared by fetchGitHubMarketplaceConfig (always HTTPS URLs) and the direct-JSON fallback path. Protocol-based client selection handles both correctly — GitHub API/raw URLs stay on https, direct HTTP URLs now use http.
• The test properly mocks node:http, asserts http.get was called with the right args, and asserts https.get was NOT called — covering both the positive and negative case.
• beforeEach default mock returns 404 for both clients, so existing tests that don't care about HTTP still behave correctly.

No correctness bugs, no security issues, no convention violations found.

Real-Scenario Test (tmux)

Started a real python3 -m http.server on port 18765 serving a marketplace.json with 2 plugins. Drove loadMarketplaceConfigFromSource('http://127.0.0.1:18765/marketplace.json') through the built packages/core/dist — once on base (main), once with the PR patch applied.

Before (base/main — https.get only)

runner@runnervm7b5n9:~/work/qwen-code/qwen-code$ echo '=== BEFORE (base/main — https.get only) ===' && HTTP_PORT=18765 node tmp/triage-marketplace/test-script.mjs 2>&1; echo '--- EXIT CODE:' $?
=== BEFORE (base/main — https.get only) ===
Fetching marketplace from: http://127.0.0.1:18765/marketplace.json
ERROR: Protocol "http:" not supported. Expected "https:"
file:///home/runner/work/qwen-code/qwen-code/packages/core/dist/src/extension/marketplace.js:115
            req.destroy();
            ^

ReferenceError: Cannot access 'req' before initialization
    at Timeout._onTimeout (file:///home/runner/work/qwen-code/qwen-code/packages/core/dist/src/extension/marketplace.js:115:13)
    at listOnTimeout (node:internal/timers:585:17)
    at process.processTimers (node:internal/timers:3925:17)

Node.js v22.22.3
--- EXIT CODE: 1

After (PR fix — protocol-aware client selection)

runner@runnervm7b5n9:~/work/qwen-code/qwen-code$ echo '=== AFTER (PR fix — protocol-aware client selection) ===' && HTTP_PORT=18765 node tmp/triage-marketplace/test-script.mjs 2>&1; echo '--- EXIT CODE:' $?
=== AFTER (PR fix — protocol-aware client selection) ===
Fetching marketplace from: http://127.0.0.1:18765/marketplace.json
SUCCESS: Loaded marketplace "triage-test-marketplace" with 2 plugins
--- EXIT CODE: 0

Unit Tests

cd packages/core && npx vitest run src/extension/marketplace.test.ts

 ✓ src/extension/marketplace.test.ts (26 tests) 19ms

 Test Files  1 passed (1)
      Tests  26 passed (26)

ESLint clean on both changed files.

中文说明

代码审查

在阅读 diff 之前，我的独立方案完全相同：导入 node:http，检查 new URL(url).protocol，在 http 和 https 之间分支。PR 的实现与此一致。

实现简洁正确：

• fetchUrl 被 fetchGitHubMarketplaceConfig（始终 HTTPS URL）和直接 JSON 回退路径共享。按协议选择 client 对两者都正确处理——GitHub API/raw URL 继续走 https，直接 HTTP URL 现在走 http。
• 测试正确地 mock 了 node:http，断言 http.get 以正确参数被调用，同时断言 https.get 未被调用——覆盖了正向和反向用例。
• beforeEach 默认 mock 对两个 client 都返回 404，不关心 HTTP 的既有测试仍然行为正确。

未发现正确性 bug、安全问题或规范违反。

真实场景测试（tmux）

启动真实的 python3 -m http.server 在端口 18765 上提供包含 2 个插件的 marketplace.json。通过编译后的 packages/core/dist 调用 loadMarketplaceConfigFromSource('http://127.0.0.1:18765/marketplace.json')——分别在 base (main) 和 PR 补丁上测试。

修复前（base/main — 仅 https.get）

ERROR: Protocol "http:" not supported. Expected "https:"
--- EXIT CODE: 1

修复后（PR — 按协议选择 client）

SUCCESS: Loaded marketplace "triage-test-marketplace" with 2 plugins
--- EXIT CODE: 0

单元测试

26/26 通过。ESLint 在两个改动文件上均通过。

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

Stepping back: this is a textbook minimal bugfix. The problem is real and well-documented — fetchUrl hardcoded https.get while its callers could receive http:// URLs. The fix is three lines that do exactly one thing: pick the right Node HTTP client based on URL protocol.

My independent proposal was identical to what the PR does, which is a good sign — there's no simpler path being missed. Every line in the diff earns its place: the import, the protocol check, the client swap, the test, the docstring update. Nothing extra.

The tmux test confirms the fix end-to-end: base throws the exact error the issue describes, PR loads the marketplace JSON successfully. Unit tests pass (26/26), ESLint clean. No regressions in the HTTPS path.

The PR is cross-repository from a first-time contributor. The PR body follows the template well, the motivation is clear, and the linked issue (#5451) provides the bug report. This is ready to ship.

Approving. ✅

中文说明

总结：这是一个教科书式的最小 bug 修复。问题真实且有据可查——fetchUrl 硬编码使用 https.get，而调用方可能收到 http:// URL。修复只有三行代码，只做一件事：根据 URL 协议选择正确的 Node HTTP client。

我的独立方案与 PR 完全一致——没有更简单的路径被遗漏。diff 中的每一行都有存在的必要：导入、协议检查、client 切换、测试、文档更新。没有多余内容。

tmux 测试端到端确认了修复：base 抛出与 issue 描述完全相同的错误，PR 成功加载 marketplace JSON。单元测试全部通过（26/26），ESLint 干净。HTTPS 路径无回归。

PR 来自首次贡献者的跨仓库提交。PR 内容很好地遵循了模板，动机清晰，关联的 issue (#5451) 提供了 bug 报告。可以合并。

批准 ✅

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅