When a client provides a badly formatted URL path, the exception is handled differently for http/1.1 and http/2. http/1.1 will respond with a 400 status code, but http/2 will close the connection with no response.

This matters because it means clients can bring down the service availability metrics by sending badly formatted requests.

There should be a way to configure Undertow so that badly formatted http/2 requests receive a 400 status.

Undertow version: 2.3.7.Final

http/1.1

curl -Sf 'http://localhost:8080/%^$^&%$'
curl: (22) The requested URL returned error: 400

Relevant source code

// io.undertow.server.protocol.http.HttpReadListener.java:257
catch (Throwable t) {
  sendBadRequestAndClose(connection.getChannel(), t);
  return;
}

http/2

curl -Sf --http2-prior-knowledge 'http://localhost:8080/%^$^&%$'
curl: (56) Failure when receiving data from the peer

This is interpreted as a 503 status by proxies.

Relevant source code

// io.undertow.server.protocol.http2.Http2ReceiveListener.java:126
catch (Throwable t) {
  UndertowLogger.REQUEST_IO_LOGGER.handleUnexpectedFailure(t);
  IoUtils.safeClose(channel);
}