Add CONNECT constant to HttpMethod

[v-perfilev]

While reviewing issue #34044, I noticed that the HttpMethod class does not include a constant for the HTTP method CONNECT, which was introduced in RFC 7231. This PR adds the CONNECT constant to the HttpMethod class and updates the test class HttpMethodTests.

Changes in other files:

• CONNECT method excluded in initAllowedHttpMethods of RequestMappingInfoHandlerMapping and in initAllowHeader of WebContentGenerator.

• CONNECT method is not supported by HttpComponentsClientHttpConnector and JdkClientHttpConnector, so ClientHttpConnectorTests was updated to dynamically skip CONNECT for these connectors.

• CONNECT method is primarily used for establishing tunnels, so it is not relevant for RequestMethod class and was excluded from RequestMethodTests.

These changes prepare the repository for a follow-up PR addressing issue #34044, where a conditional check will be introduced for WebSocket handshakes: if the HTTP version is HTTP/2 the method must be CONNECT, as specified in RFC 8441, otherwise it should be GET.

[snicoll]

Additionally the documentation references for existing constants in HttpMethod have been updated to point to the RFC 9110, as the previous links referenced a superseded document.

Please revert, this is unrelated to your proposal of adding CONNECT.

[v-perfilev]

Hello @snicoll !

Done: the commit with link updates has been reverted as requested.

1. Would you like me to create a separate PR for this change, or should I leave it for now?
2. Do the same 55-character length rule apply to revert commit messages?

[snicoll]

Let's see where this PR leads us and we can revisit the other change. The rule (not sure where that comes from) is irrelevant as your commits are going to be squashed if we merge this.

[v-perfilev]

@snicoll
Okay, I got it.
This rule comes from CONTRIBUTING.md:

Format commit messages using 55 characters for the subject line, 72 characters per line for the description.

[bclozel]

@v-perfilev I understand that CONNECT is an HTTP method defined in specs, but is there a use case in Spring Framework where we can send or receive HTTP CONNECT requests? I'm asking because adding it in HttpMethod has little value if we're ignoring this value totally in our HTTP support.

[v-perfilev]

Hi @bclozel !

I noticed that the CONNECT method was missing while trying to resolve the issue #34044. At the moment, WebSocket handshake over HTTP/2 is not supported in Spring Framework. According to RFC the CONNECT method must be used for HTTP/2 WebSocket handshakes instead of GET. The HttpMethod class is the most logical place to add this constant. Otherwise, we would need to define and use the CONNECT constant directly in AbstractHandshakeHandler in the following way:

private static final String CONNECT_HTTP_METHOD = "CONNECT"; // DEFINITION

@Override
public final boolean doHandshake(ServerHttpRequest request, ServerHttpResponse response,
        WebSocketHandler wsHandler, Map<String, Object> attributes) throws HandshakeFailureException {
    String protocol = request.getHeaders().getFirst("x-http2");
    boolean isHttp2 = "h2".equals(protocol);

    // some code

    if (isHttp2 && CONNECT_HTTP_METHOD != request.getMethod()) { // USAGE
        // some code
    }

    if (!isHttp2 && HttpMethod.GET != request.getMethod()) {
        // some code
    }

    // some code
}

This is not the only case where the CONNECT method is used. CONNECT is indispensable for building proxy-based and tunneling architectures, Spring Framework can also be used for.

Finally, having the CONNECT method ensures consistency within the industry standards. Similar rarely used method TRACE is already part of HttpMethod, and libraries like Apache HttpClient and Netty already support the CONNECT method.

Regards,
Vladimir

[bclozel]

I'm not sure how we could produce CONNECT requests with RestTemplate or RestClient as this method is meant to be used by transport protocols, not high level clients.

As for #34044, I've already commented there that I don't think we can use this method in our support as Servlets do not support this HTTP method at the moment. I'll leave this opened for now until we hear from the reporter on #34044

[rstoyanchev]

Thanks for the PR, but we are going to make a more targeted change in AbstractHandshakeHandler. It makes sense to support the method of upgrade in RFC 8441, but there is no intent to support HTTP CONNECT more widely.