Jetty version(s)

12.1.0.beta1

Jetty Environment

ee10

Description

I'm currently try to use the new Servlet Upgrade support but found some issues, if I call the method:

https://jakarta.ee/specifications/servlet/6.0/apidocs/jakarta.servlet/jakarta/servlet/http/httpservletrequest#upgrade(java.lang.Class)

jetty checks several conditions on the response(!)

    if (response.getStatus() != HttpStatus.SWITCHING_PROTOCOLS_101)
        throw new IllegalStateException("Response status should be 101");
    if (response.getHeaders().get("Upgrade") == null)
        throw new IllegalStateException("Missing Upgrade header");
    if (!"Upgrade".equalsIgnoreCase(response.getHeaders().get("Connection")))
        throw new IllegalStateException("Invalid Connection header");
    if (response.isCommitted())
        throw new IllegalStateException("Cannot upgrade committed response");
    if (_servletChannel.getConnectionMetaData().getHttpVersion() != HttpVersion.HTTP_1_1)
        throw new IllegalStateException("Only requests over HTTP/1.1 can be upgraded");

None of these conditions are described in the API though and instead it says:

Creates an instance of HttpUpgradeHandler for a given class and uses it for the http protocol upgrade processing

So my expectation would be that (if such checks are need to be made) not earlier than before sending the actual response to the client. This is also reflected by throw new IllegalStateException("Cannot upgrade committed response"); so before the response is actually committed I could modify anything that is checked here anyways (or should be, see below!).

I would also expect it to automatically set SWITCHING_PROTOCOLS_101 or Upgrade: Connection if it is the only valid choice anyways and missing at these point.

Another issue (compared to implementation in other webservers) seem that creating the handler commits the response as well as calling init with the web connection, so a handler has no real chance to perform anything after construction time (and one can't pass a prebuild instance to the method), what makes it returning the handler from the method quite useless in many cases.

Also the Javadoc mentions

It is called once the HTTP Upgrade process has been completed

So unless I have created my handler and the response is written I suppose it can not be claimed to be completed.

Also the spec describes the process as follows:

When an upgrade request is received, the servlet can invoke the HttpServletRequest.upgrade method, which starts the upgrade process. This method instantiates the given HttpUpgradeHandler class. The returned HttpUpgradeHandler instance may be further customized.

and later on

After exiting the service method of the servlet, the servlet container completes the processing of all filters and marks the connection to be handled by the HttpUpgradeHandler. It then calls the HttpUpgradeHandler's init method, passing a WebConnection to allow the protocol handler access to the data streams.

So long story short I would expect that HttpServletRequest.upgrade(Class<T>) only creates the handler and performs whatever book keeping is required. Then after the service method of the Servlet (or Filter) is done the checks are performed and the HttpUpgradeHandler.init(WebConnection) is called (possibly asynchronous). Currently the init happens to early (e.g. as part of the method call).