Support for separate registration and published endpoint paths in WebMvcSseServerTransportProvider

[minguncle]

Please do a quick search on GitHub issues first, the feature you are about to request might have already been requested.

Expected Behavior
WebMvcSseServerTransportProvider should support separate configuration for registration paths and published paths. This would allow proper operation in environments with context paths or global URL prefixes. Example usage:
// Registration path: /message (for server routing)
// Published path: /api/v1/message (what clients see/use)
var transportProvider = new WebMvcSseServerTransportProvider(
objectMapper,
"/message", // Server registration path
"/api/v1/message", // Path sent to clients
"/sse"
);
With this enhancement, the server would register handlers at the bare paths, but communicate the full paths to clients through the SSE connection.

Current Behavior

When using WebMvcSseServerTransportProvider in environments with servlet context paths or other global URL prefixes (like Spring Boot's spring.mvc.servlet.path), there's a mismatch between:

1. The path where handlers are registered with Spring's RouterFunction (e.g., /message)
2. The full path that needs to be communicated to clients (e.g., /app/message when the context path is /app)

Currently, WebMvcSseServerTransportProvider uses the same path for both registration and client communication, which doesn't work correctly in environments with context paths.
Context

I'm deploying an MCP server in a Spring Boot application with a servlet context path configured via spring.mvc.servlet.path. When registering message endpoints with Spring's RouterFunction, I need to use paths without the context prefix, but when communicating these endpoints to clients, I need to include the full path with context prefix. I've considered workarounds like:

1. Using a reverse proxy to handle path translation (adds complexity)
2. Manually modifying paths in client code (error-prone)
3. Implementing a custom transport provider (duplicates existing code)
   A simple solution would be to enhance WebMvcSseServerTransportProvider to support separate configuration for registration and published paths, which would resolve this issue cleanly.

[aronsemle]

I second this one! I was trying to host using Grizzly on /ai/sse and /ai/mcp/message endpoints and it wouldn't work because of this. I have it working on root /sse and /mcp/message but that's not ideal.

I'd guess I'd only ask if it's worth the endpoint checks in the doGet and doPost handlers? Grizzle gives me control over the routing so why check it again here? Maybe what it's doing now is the best convention but worth asking.

// Example
if (!this.messageEndpoint.equals(pathInfo)) {
response.sendError(404);
} else {

[tzolov]

@minguncle, this should affect the /sse endpoint as well, right? For example, you would need to access it on /app/sse (if the context is set to app).

How do you resolve this? By setting the sseEndpoint="/app/sse" in the WebMvcSseServerTransportProvider constructor?

Also, I believe this is the same issue but for WebFlux: #102

I kind of like the baseUrl + messageEndpoint approach rather than the publishedMessageEndpoint. I might modify your PR along those lines before merging.

[tzolov]

@aronsemle I guess you're experiencing this issue but using the core HttpServletSseServerTransportProvider transport? I guess we can apply the same baseUrl + messageEndpoint approach there as well?

[aronsemle]

@tzolov yes! That would be great if it was also applied to the HttpServletSseServerTransportProvider.

[krzysztof-osiecki]

@tzolov any idea when we can expect version with this change?