fix: use agent function to support HTTP/HTTPS protocol switching in self-hosted GitLab

[Copilot]

Self-hosted GitLab instances behind HTTPS proxies often return http:// URLs in API responses or issue HTTP redirects internally. node-fetch was configured with a static agent (e.g., HTTPS-only), so any protocol switch during redirects would fail with Protocol "http:" not supported. Expected "https:".

Changes

• gitlab-client-pool.ts: Add getAgentFunctionForUrl() returning a (parsedURL: URL) => Agent function that dynamically selects HTTP or HTTPS agent per-request. Extract shared agent lookup into private getOrCreateAgentsForUrl().
• index.ts: Switch getFetchConfig() from static agent to agent function.

node-fetch supports an agent function that is called per-request, including on redirects:

// Before: static agent breaks on protocol switch
agent: clientPool.getOrCreateAgentForUrl(effectiveApiUrl)

// After: function selects correct agent per URL
agent: clientPool.getAgentFunctionForUrl(effectiveApiUrl)
// returns (parsedURL: URL) => parsedURL.protocol === "https:" ? httpsAgent : httpAgent

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Self-hosted GitLab with HTTP: "Protocol 'http:' not supported" error</issue_title>
<issue_description>## Description

When using a self-hosted GitLab instance that returns http:// URLs in API responses (e.g. self links, resource URLs), some operations fail with:

MCP error -32603: Protocol "http:" not supported. Expected "https:"

This happens even when GITLAB_API_URL is set to https://. The issue is that GitLab API responses may contain internal links using http:// (common in self-hosted setups where external_url differs from the actual protocol), and the MCP server's HTTP client rejects them.

Steps to reproduce

1. Configure a self-hosted GitLab instance that returns http:// in API response bodies
2. Set GITLAB_API_URL=https://gitlab.example.com/api/v4
3. Call any tool that follows URLs from API responses, e.g. get_project

Expected behavior

The server should handle http:// URLs from API responses, or at minimum use the protocol from GITLAB_API_URL when constructing follow-up requests.

Actual behavior

Error: MCP error -32603: Protocol "http:" not supported. Expected "https:"

Workaround ...

• Fixes Self-hosted GitLab with HTTP: "Protocol 'http:' not supported" error #370

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Copilot]

Pull request overview

Updates the GitLab HTTP client configuration to support protocol switching (HTTP ↔ HTTPS) during redirects and when following http:// links returned by some self-hosted GitLab instances, avoiding node-fetch agent/protocol mismatch errors.

Changes:

• Introduces getAgentFunctionForUrl() in the GitLab client pool to dynamically select an HTTP vs HTTPS agent per request URL.
• Refactors shared agent-pair lookup/creation into a private getOrCreateAgentsForUrl() helper.
• Switches index.ts fetch configuration to use the new agent function instead of a static agent instance.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
gitlab-client-pool.ts	Adds an agent-selection function (and shared agent-pair retrieval) to handle protocol changes across redirects/URLs.
index.ts	Uses the agent function in getFetchConfig() so node-fetch can pick the correct agent per request/redirect.

Comments suppressed due to low confidence (1)

gitlab-client-pool.ts:112

• The new protocol-switching behavior (agent function selecting HTTP vs HTTPS agents) is a regression-prone fix, but there’s no automated test exercising it. Consider adding a small unit test for getAgentFunctionForUrl() that asserts the returned function selects httpAgent for http: URLs and httpsAgent for https: URLs (and ideally covers the original failure mode via a simulated redirect/protocol switch).

  private createAgentsForUrl(apiUrl: string): ClientAgents {
    const { httpProxy, httpsProxy, noProxy, rejectUnauthorized, caCertPath } = this.options;
    const url = new URL(apiUrl);

    let sslOptions: { rejectUnauthorized?: boolean; ca?: Buffer } = {};

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.