AbstractHandshakeHandler should support RFC 8441 WebSocket upgrade via CONNECT with HTTP/2

[jazdw]

If the web server advertises that it supports RFC 8441 via the HTTP/2 SETTINGS_ENABLE_CONNECT_PROTOCOL parameter then some web browsers (Chrome, Firefox) will follow RFC 8441 to open a WebSocket over a HTTP/2 stream using the CONNECT HTTP method.

The org.springframework.web.socket.server.support.AbstractHandshakeHandler#doHandshake method however only supports the GET method and will respond with 405 Method Not Allowed. and log an error message: Handshake failed due to unexpected HTTP method: CONNECT

The work around is to disable RFC 8441 in your web server, e.g. with Jetty you can set org.eclipse.jetty.http2.server.AbstractHTTP2ServerConnectionFactory#setConnectProtocolEnabled to false (the default is that it is enabled in Jetty 12 EE10).

This problem was observed in Spring 6.2.0.

spring-framework/spring-websocket/src/main/java/org/springframework/web/socket/server/support/AbstractHandshakeHandler.java

Lines 172 to 179 in f8fd6da

	if (HttpMethod.GET != request.getMethod()) {
	response.setStatusCode(HttpStatus.METHOD_NOT_ALLOWED);
	response.getHeaders().setAllow(Collections.singleton(HttpMethod.GET));
	if (logger.isErrorEnabled()) {
	logger.error("Handshake failed due to unexpected HTTP method: " + request.getMethod());
	}
	return false;
	}

[bclozel]

@jazdw As far as I understand the Servlet spec does not support CONNECT requests. Can you explain what kind of support you're asking here?

[jazdw]

@jazdw As far as I understand the Servlet spec does not support CONNECT requests. Can you explain what kind of support you're asking here?

I'm asking for Spring to support RFC 8441 WebSocket upgrades. I noticed that out of the box on Jetty 12 EE 10 the WebSocket upgrades didn't work so I opened an issue.

Here's a link to the relevant section of the Servlet spec - https://github.com/markt-asf/servlet-api/blob/master/spec/src/main/asciidoc/servlet-spec-body.adoc#213-additional-methods

The CONNECT method applies to proxies whereas the Jakarta Servlet API is targeted at endpoints so, by default, Containers must reject such requests with an SC_NOT_IMPLEMENTED (501) response and not pass the request to a Filter or Servlet. Containers may provide container specific functionality to handle CONNECT requests. If that functionality includes passing CONNECT requests to a Filter or Servlet, then the container should define the expected behaviour of the Servlet API for such requests in that container.

From reading that, I don't think the statement "the Servlet spec does not support CONNECT requests" is true. It looks like it is up to the container implementation.

[bclozel]

Can we take a step back?
You have mentioned that disabling this option in Jetty is required otherwise it fails. How can we reproduce this setup? Are you using Spring Boot?

Indeed, Servlet containers can support other HTTP methods. Spring is using Servlet containers but isn't one itself. Our standard websocket upgrade is using a standard Servlet which won't support connect requests, hence my comment.

Maybe something can be done at Servlet container configuration level in Spring Boot?

[jazdw]

Can we take a step back? You have mentioned that disabling this option in Jetty is required otherwise it fails. How can we reproduce this setup? Are you using Spring Boot?

I am not using Spring Boot, this is a Jetty webserver + Spring MVC. I could create a project to reproduce this issue but I don't have time right at the moment.

Indeed, Servlet containers can support other HTTP methods. Spring is using Servlet containers but isn't one itself.

Agreed. I am using the Jetty webserver and Jetty servlet container, both of which do seem to support CONNECT.

Our standard websocket upgrade is using a standard Servlet which won't support connect requests, hence my comment.

It doesn't? Which servlet are we talking about here? The dispatcher servlet? Maybe I am misunderstanding something that will become more clear if I try and create a reproduction project. The application I am working on is pretty massive and confusing the follow. To be clear though, I observed the CONNECT request making its way through to AbstractHandshakeHandler L172 from the above snippet.

Maybe something can be done at Servlet container configuration level in Spring Boot?

Not Spring boot, but yeah you can definitely address this if you are using Jetty by setting AbstractHTTP2ServerConnectionFactory.setConnectProtocolEnabled(false) and this workaround is fine with me. I mainly just thought that Spring would probably want to start supporting RFC 8441 CONNECT upgrades for HTTP/2 since browsers support it.

[bclozel]

@jazdw thanks a lot for your feedback. We would like to support this case and we'll look into reproducing this.
Anything you can point us to (including the client side) is welcome.