Add new option to IBM WAS and Liberty to allow customers to configure WAS/Liberty to not close HTTP connections when WAS/Liberty are sending back response where the HTTP response code is greater than 399

Thank you for the suggestion. As detailed in prior comments the requested solution would not be implementable without violating the HTTP 1.1 specification and the alternative requested would be similarly unsafe. While a broad change as requested would be unsafe there are response codes above 4xx that maybe safe to hold the connection open such as 404, so we created https://github.com/OpenLiberty/open-liberty/issues/25933 to track that idea with the upstream Open Liberty project. Since that idea is significantly different from what is requested we have decided to mark this one as not being done rather than in future closing it with a different behaviour. If you would like to discuss this decision further, please contact Graham Charters <charters@uk.ibm.com>.

There isn't anything in RFC 9112 (the specification for HTTP 1.1) that says a response greater than 399 must close the connection. Instead the reason Liberty does this is due to Section 9.3 which covers the concept of persistent connections and it says the following:

In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 6. A server MUST read the entire request message body or close the connection after sending its response; otherwise, the remaining data on a persistent connection would be misinterpreted as the next request.

Some of the response codes greater than 399 indicate error conditions that mean it is either impossible or practically impossible for the server to honor this requirement. For example a request that does not set a message length could not be fully read by the server and if treated this way could result in an http smuggling vulnerability. This is highlighted in a number of other places in the RFC that explicitly call out that a 400 (bad request) response should result in the connection being closed, for example the last paragraph of section 2.2 states:

When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed above, the server SHOULD respond with a 400 (Bad Request) response and close the connection.

While this doesn't cover all error codes explicitly above 400 there are other 4xx response codes that do mean a server couldn't meet the requirements of persistent connections. Given their nature it is also unlikely that a guarantee cannot be offered for 5xx responses either. As such it would not be safe to provide a general property as requested since it would violate the persistent connections part of the HTTP 1.1 specification. The backup of allowing specific response codes to not close the connection would also likewise be unsafe since we cannot guarantee the server would correctly implement the persistent connection requirements in those cases.

Also, this is implied in the description, but this behavior only applies to persistent connections.

This is not quite accurate. This only applies to HTTP < 2.0 and this occurs for codes 400, 402-417, or 500-505: https://publib.boulder.ibm.com/httpserv/cookbook/WebSphere_Application_Server-WAS_Liberty.html#error-codes-closing-keep-alive-connections