http-custom-header-server-validation: no case sends an empty x-mcp-header value #519

Activity

1. jw-ond commented on Oct 16, 2026

   

   jw-ond

   on Oct 16, 2026

   Last edited by jw-ond

   More actions

   Codex-assisted runtime verification of modelcontextprotocol/go-sdk#1289 found a
   small complementary coverage opportunity. A real SDK HTTP/1.1 + HTTP/2 matrix
   and SDK-client round trip pass all 21 cases on the fix (c04bc77); its parent
   (8075fb3) reproduces the empty-header failures.

   I have prepared negative-only coverage in the existing conformance scenario,
   leaving your proposed empty-body/empty-header acceptance case to you:

   • Empty string body with the custom header absent: reject.
   • Optional argument omitted with a present empty header: reject.
   • Null argument with a present empty header: reject.

   Each checks HTTP 400 and -32020. The unchanged runner passes both SDKs 10/10;
   the patched runner detects four failures on the parent (12/16) and passes
   16/16 on the fix, including wire-schema validation. Deliberately broken
   real-HTTP fixtures demonstrate that both presence mistakes are caught. The
   full suite passes 645 tests, plus build and lint/typecheck.

   Would this be useful as a separate draft, or would you prefer to fold the
   negative cases into your planned PR? It does not duplicate the SDK fix, your
   positive case, or #325's omission-without-header acceptance case. Omitted/null
   probes require an optional annotated string fixture and report a missing
   fixture as untestable. The null control isolates transport, not application
   JSON Schema acceptance.

   AI disclosure: Codex authored the patch, fixtures and this comment, and ran
   the reported checks. The proposal will remain draft for scope coordination
   and contributor review; no maintainer approval or prior human code review is
   being claimed.

   Draft: #560. The pinned Go fixture and wire tests
   are available separately to reproduce the real-SDK comparison.