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

Abierto
  • ¿Algo no está bien?
#3,592 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
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

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

Lenguaje dominante
Go
Estrellas
34.2k
Forks
5.3k
Merge medio
5 d 18 h
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/github-mcp-server

Todos los issues de github/github-mcp-server

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.