Client: handle server responses with Content-Length: 0

- When the client sends `notification/initalized`, servers must respond
  with HTTP 202 and an empty body. We checked for the absence of a
  Content-Type header to verify whether the body was empty.
- However, some servers will send an empty body with a Content-Type
  header, and that header may have an unsupported, default type such as
  `text/html` or `text/plain`.
- Now we we also use the Content-Length header to check for an empty
  body. This header is optional in HTTP/2, so we do not make it our
  primary mechanism for detecting empty bodies.
- As part of this PR, we also move hard-coded HTTP header names to the
  HttpHeaders interface. While they are not defined by the MCP spec,
  they are used by it and are core to implementing the protocol.
  Therefore, they have their place in a core interface.
- Fixes #582

Signed-off-by: Daniel Garnier-Moiroux <git@garnier.wf>

mcp-spring/mcp-spring-webflux/src/main/java/io/modelcontextprotocol/client/transport/WebClientStreamableHttpTransport.java

@@ -293,9 +293,10 @@ public class WebClientStreamableHttpTransport implements McpClientTransport {
 					// 200 OK for notifications
 					if (response.statusCode().is2xxSuccessful()) {
 						Optional<MediaType> contentType = response.headers().contentType();
+						long contentLength = response.headers().contentLength().orElse(-1);
 						// Existing SDKs consume notifications with no response body nor
 						// content type
-						if (contentType.isEmpty()) {
+						if (contentType.isEmpty() || contentLength == 0) {
 							logger.trace("Message was successfully sent via POST for session {}",
 									sessionRepresentation);
 							// signal the caller that the message was successfully