modelcontextprotocol/python-sdk#1353 for python SDK if this is accepted

@pja-ant is there a RFC reference we can include that rationalizes the response code?

@pja-ant is there a RFC reference we can include that rationalizes the response code?

Hey @dend. You mean a SEP? Thought that might be overkill, but happy to put one together if you feel it's needed here. The SEP guidelines state (emphasis mine):

The goal is to reserve the SEP process for changes that are substantial enough to require broad community discussion, a formal design document, and a historical record of the decision-making process. A regular GitHub issue or pull request is often more appropriate for smaller, more direct changes.

My sense is that this isn't super substantial, but at the end of the day I'm the noob here so I'll do whatever people like!

In terms of the rationalization: between 400 and 403 (the only two contenders in my opinion), I feel 403 is most appropriate since 400 generally means some sort of "client error" where the server couldn't process even if it wanted whereas 403 "indicates that the server understood the request but refuses to fulfill it", which is exactly what's happening here.

I think this is fine without a SEP. @localden @pcarleton, any objections to defining 403's?

@pja-ant can you add a minor changelog entry?

👍 looks reasonable to me, and agree it doesn't need a SEP.

I think Den was asking if there are HTTP RFC's to reference to back up the decision on 403 vs. 400, and I agree with @pja-ant 's read of RFC 9110 that 403 is better here.

cc @ochafik as a bookmark for a good conformance test

Thanks for the improvement introduced in this PR, the added clarification definitely helps.
However, I believe the original top-level requirement:

“Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks”

still needs refinement to accurately reflect when DNS rebinding protection is relevant and to avoid creating unintended non-compliance in existing SDKs.

As written, the statement implies that all MCP servers, in all environments, must enforce Origin validation. This has two issues:

1. It conflicts with the current Typescript SDK behavior.
   The SDK defaults enableDnsRebindingProtection to false. If the specification literally requires unconditional validation of the Origin header for DNS rebinding protection, the SDK would not comply with the standard, as it implies that enableDnsRebindingProtection should always be true. Moreover, enabling the protection (true) currently blocks requests from non-browser clients, since they typically do not send an Origin header and validateRequestHeaders rejects them.
2. DNS rebinding mitigation only makes sense for local deployments.
   The threat model is specific to browser-initiated requests targeting local MCP servers. Public servers are not affected by DNS rebinding, so enforcing Origin validation on all connections "to prevent DNS rebinding attacks" is unnecessary and misleading.

For these reasons, I suggest at least rephrasing the requirement to scope it appropriately:

“When running locally, Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks.”

Even better, since Host validation is the actual mechanism required to prevent DNS rebinding:

“When running locally, Servers MUST validate the Host header and the Origin header on all incoming connections to prevent DNS rebinding attacks.”

However, enforcing Origin validation after Host validation should be optional and not mandatory (when running locally).

Please let me know if you would prefer that I file a separate issue for these remarks.