Description

The _validate_gateway_url method in mcpgateway/services/gateway_service.py (lines 357-407) has non-standard redirect handling for STREAMABLEHTTP transport that may cause confusion and maintenance issues.

Current Behavior

When transport_type="STREAMABLEHTTP", the validation logic:

1. Makes a GET request to the gateway URL
2. Checks for a location header in the response (regardless of HTTP status code)
3. If a location header is present, treats it as a redirect and makes a second request to that URL
4. Validates the redirected response has mcp-session-id header and application/json content-type

Code Reference

This block occurs after the function has already made an initial request. Notice that if there is no response, the if logic falls through and the verification eventually returns False.

if transport_type == "STREAMABLEHTTP":
    if location:
        async with validation_client.client.stream("GET", location, headers=headers, timeout=timeout) as response_redirect:
            response_headers = dict(response_redirect.headers)
            mcp_session_id = response_headers.get("mcp-session-id")
            content_type = response_headers.get("content-type")
            if response_redirect.status_code in (401, 403):
                logger.debug(f"Authentication failed at redirect location {location}")
                return False
            if mcp_session_id is not None and mcp_session_id != "":
                if content_type is not None and content_type != "" and "application/json" in content_type:
                    return True

Issues

1. Non-standard HTTP behavior: The code treats any response with a location header as a redirect, without checking for proper 3xx status codes (301, 302, 307, 308, etc.)

2. Undocumented protocol: Is this "200 OK with location header" pattern documented in the MCP specification or StreamableHTTP protocol? If not, it creates confusion about expected server behavior.

3. Reinventing redirect handling: httpx library already has robust redirect-following capabilities that handle:

   • Proper 3xx status code checking
   • Redirect loop detection
   • Maximum redirect limits
   • Preservation of request methods and bodies per RFC standards

Questions

1. Is the requirement for a 200 HTTP response with a "location" header part of a documented standard for StreamableHTTP?
2. If this is custom behavior specific to this implementation, should it be documented?

Recommendation

If this isn't a documented standard, consider:

1. Use httpx's built-in redirect handling:

   validation_client = ResilientHttpClient(
       client_args={
           "timeout": settings.gateway_validation_timeout,
           "verify": not settings.skip_ssl_verify,
           "follow_redirects": True,  # Let httpx handle redirects properly
           "max_redirects": 5
       }
   )

2. Simplify the validation logic to check final response attributes after httpx has followed any proper HTTP redirects

3. Document the expected behavior if the current "location header without 3xx status" pattern is intentional

Impact

• Confusion for developers implementing MCP gateway servers
• Potential incompatibility with standard HTTP redirect behavior
• Maintenance burden of custom redirect logic
• Test complexity (as evidenced by the recent test refactoring in PR #XXX)

Environment

• Component: mcpgateway/services/gateway_service.py
• Method: _validate_gateway_url (lines 357-407)
• Transport: STREAMABLEHTTP