Remote MCP OAuth protected-resource metadata returns invalid duplicate Content-Type

The report identifies the hosted protected-resource metadata endpoint, but does not name a repository file or establish which component adds the duplicate header. Start by tracing how this endpoint is served and where its response headers are set, then check any middleware or edge handling in scope. Done means the hosted endpoint returns the JSON metadata with exactly one valid Content-Type: application/json header over both HTTP/1.1 and HTTP/2.

Describe the bug

This issue is observed only with the remote MCP server. Please redirect me to the right place if it's not for here.

I encountered an OAuth discovery failure while connecting a client built with the official MCP Go SDK to GitHub's hosted Remote MCP server at https://api.githubcopilot.com/mcp/. The SDK rejected the protected-resource metadata response because its Content-Type was invalid.

During OAuth discovery, the client fetches https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp/ to learn which authorization server to use. That endpoint returns a JSON document with HTTP 200, but the response received by curl contains this header:

content-type: application/json,application/json

To isolate the HTTP response from the SDK integration, the metadata endpoint was queried directly with curl on 2026-10-26. All four checks below received the invalid combined value, using HTTP/1.1 and HTTP/2 and paths with and without a trailing slash. No access token, cookie, or OAuth application is needed for these requests.

These curl captures show one field line containing a combined value. They do not establish whether the origin emitted two separate fields that an intermediary combined. A historical capture in #1804 shows two separate Content-Type fields; see the related evidence below.

Affected version

GitHub-hosted Remote MCP service at https://api.githubcopilot.com/mcp/, observed 2026-10-26 at 11:27 UTC. The hosted service does not expose a build version in these responses; this is not a local Docker deployment.

Client: curl 8.5.0 on x86_64 Linux, libcurl 8.5.0, OpenSSL 3.0.13, nghttp2 1.59.0.

Steps to reproduce the behavior

Run the following GET, then repeat with --http1.1 and with the trailing slash removed:

curl --http2 --silent --show-error --include \
  --header 'Accept: application/json' \
  --write-out '\nNEGOTIATED_HTTP=%{http_version} STATUS=%{response_code}\n' \
  'https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp/'

Results from four separate requests:

Metadata path	HTTP version reported by curl	Status	Content-Type	X-GitHub-Request-Id
/.well-known/oauth-protected-resource/mcp/	1.1 (forced)	200	application/json,application/json	9761:B4797:83710A7:8FD58FC:6ADF38FD
/.well-known/oauth-protected-resource/mcp/	2	200	application/json,application/json	9761:B4797:837BD84:8FE0F19:6ADF3920
/.well-known/oauth-protected-resource/mcp	1.1	200	application/json,application/json	9761:B4797:837BB44:8FE0CBC:6ADF390D
/.well-known/oauth-protected-resource/mcp	2	200	application/json,application/json	9761:B4797:8388D24:8FEEA69:6ADF3920

Expected vs actual behavior

Expected: HTTP 200, a JSON metadata document, and exactly one valid Content-Type: application/json field.

Actual: The JSON document is returned, but the delivered Content-Type value contains two comma-separated media types.

RFC 9728 §3.2 requires a successful metadata response to use application/json. RFC 9110 §8.3 defines Content-Type as a singleton media type and discusses the interoperability problems caused by duplication. Repeated singleton field lines also conflict with the sender requirements in RFC 9110 §5.3.

Impact: The invalid header prevents clients that validate the metadata media type from accepting the document and continuing OAuth discovery, even though the status is 200 and the body is valid JSON.

The official MCP Go SDK's oauthex.getJSON at commit 0f33af19994c7ed0edf3c12211b51e4bfd2cbece reads Content-Type, parses it with mime.ParseMediaType, and rejects a parsing error or a media type other than application/json. For the combined value captured here, this code would return bad content type "application/json,application/json".

The fresh reproduction above tests the HTTP response with curl. The SDK behavior was checked by inspecting the linked source, rather than by executing an SDK client. The SDK version and exact error text from the original integration are not specified in this report, so the pinned source is supporting evidence, not an identification of that integration's version.

Please ensure the hosted metadata response path emits Content-Type once, including across any middleware or edge layers.

Logs

Complete final HTTP response from the HTTP/2 trailing-slash request:

HTTP/2 200
access-control-allow-headers: Content-Type
access-control-allow-methods: GET, OPTIONS
access-control-allow-origin: *
content-length: 328
content-security-policy: default-src 'none'; sandbox
content-type: application/json,application/json
date: Mon, 26 Oct 2026 11:27:28 GMT
strict-transport-security: max-age=31536000
x-copilot-service-request-id: 79b8f61a-00d0-4a54-9c05-3273c28c7d1e
x-github-backend: Kubernetes
server: envoy
x-github-request-id: 9761:B4797:837BD84:8FE0F19:6ADF3920
x-github-edge-region: iad
x-envoy-upstream-service-time: 121

{"resource":"https://api.githubcopilot.com/mcp/","authorization_servers":["https://github.com/login/oauth"],"scopes_supported":["repo","read:org","read:user","user:email","read:packages","write:packages","read:project","project","gist","notifications"],"bearer_methods_supported":["header"],"resource_name":"GitHub MCP Server"}

curl also reported NEGOTIATED_HTTP=2 STATUS=200; it exited successfully.

Capture qualification: These fresh checks used a managed execution environment's network egress. The dump above is the final endpoint response as delivered to curl; an initial proxy connection response is omitted. It establishes the invalid delivered value, but does not establish whether GitHub originally emitted two field lines that an intermediary combined, or one already-combined field, nor identify the component responsible.

Related historical evidence

• https://github.com/github/github-mcp-server/issues/1804 includes a January 2026 curl capture with two separate content-type: application/json fields. That issue primarily concerns malformed metadata discovery URLs and is closed as not planned.
• https://github.com/microsoft/vscode/issues/259251 includes a trace with the combined Content-Type value; its primary issue is resource identifier matching.

This report focuses specifically on the invalid metadata response Content-Type, independently of those discovery URL and resource identifier problems.