Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

[Server] Let a framework integration opt out of the HTTP edge middleware without a warning

已關閉
#523 4 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
62/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
php
領域
api, backend, security

研究方向

Start with StreamableHttpTransport's empty-middleware warning and handshakeMiddleware(), then trace how Drupal's mcp_server integration supplies the empty list. Define an explicit opt-out that suppresses only the deliberate warning while preserving protocol validation, and keep accidental empty lists distinguishable.

由索引模型根據 Issue 內容生成。

描述

enhancement Server

StreamableHttpTransport logs a warning whenever it gets an empty middleware list (added in #307):

Streamable HTTP transport started with an empty middleware list. Default security protections (CORS, DNS rebinding, protocol version validation) are disabled. …

In the Drupal integration (mcp_server), the empty list is deliberate. Drupal's HTTP layer already handles both edge checks:

  • CORS comes from Drupal's cors.config. CorsMiddleware would add a second set of CORS headers.
  • Host validation comes from Drupal's trusted_host_patterns, which are regular expressions. DnsRebindingProtectionMiddleware takes an exact host list and answers 403 for any host not on it.

Since 0.8, the protocol version check runs through handshakeMiddleware() no matter what list is passed, so the "protocol version validation" part of the message no longer applies.

PHP builds a new transport for every request, so this warning becomes one log entry per MCP request on every Drupal site using the SDK.

Could the transport accept an explicit opt-out that doesn't warn? For example, a constructor flag, or a documented value that means "the host application handles CORS and Host validation". The warning still makes sense for an accidental [].

Downstream: https://git.drupalcode.org/project/mcp_server/-/work_items/3585939

主要語言
PHP
星號
1.6k
分支
180
平均合併
3 天 12 分鐘
30 天內合併 PR
44

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

modelcontextprotocol/php-sdk 的其他 Issue

查看 modelcontextprotocol/php-sdk 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。