Explicit default-port Origin entries reject browser-serialized origins

[austintraver]

Configuring StreamableHttpServerConfig::allowed_origins with https://client.example:443 rejects Origin: https://client.example with HTTP 403. Supplying Origin: https://client.example:443 succeeds. This prevents an explicit default-port entry from matching the origin’s normal browser serialization.

Reproduced with rmcp 3.3.0 through a Streamable HTTP server, using MCP Inspector CLI to call a tool with each Origin header explicitly supplied:

Allowed entry	Request Origin	Observed	Expected
https://client.example:443	https://client.example	HTTP 403	Accepted
https://client.example:443	https://client.example:443	Accepted	Accepted
https://client.example:443	https://client.example:8443	HTTP 403	HTTP 403
https://client.example	https://client.example:8443	Accepted	Accepted

RFC 6454 §4 assigns an omitted port the scheme’s default; §6.2 omits that default port when serializing an origin. The current matcher instead compares the incoming absent port directly against the configured explicit port.

Please compare an explicitly configured port against the incoming origin’s effective port: 443 for HTTPS and 80 for HTTP when omitted. Preserve the existing rule that an omitted configured port permits any port. This makes default-port restrictions work through the existing configuration while retaining the wildcard behavior that Spice intentionally uses.

The rustdoc should describe that distinction: an omitted configured port permits any port; an explicit configured port restricts matching to that effective port. This preserves the omitted-port policy left unchanged by #1191 and #1192.