Apache closes Keep-Alive connection after HTTP 401

SUSE Linux Enterprise Server 12 SP5
SUSE Linux Enterprise Server 15 SP2 
SUSE Linux Enterprise Server 15 SP3

Change in behavior of handling 'Expect: 100-Continue' in apache-2.4.51-35.4.1 with respect to the older apache-2.4.23-29.80.1.

With the new apache 2.4.51-35.4.1 released on SLES 12-SP5, when the 'Expect: 100-Continue' is set, apache closes the connection when it receives final response from the backend, even if 'keepalive' bit is set.

For example, if the backend requires authentication, and it receives POST request from the client with no authentication information, then it sends final answer to the fronted (apache), which in turn, closes the connection with the client, unlike previous versions of apache which kept the connection alive. (apache versions prior to 2.4.48).

If the above new behavior is causing issues, the client can take one of the following approaches:

1. Send the required authentication data with the initial request, setting 'Expect: 100-Continue'.

2. Don't set 'Expect: 100-Continue' in the request header, and simply push the whole body together with the initial request header.

When the client is using the 'Expect: 100-Continue' feature, the following events occur with apache version >= 2.4.48.

1. Initial TCP connection to the server.
2. Client send initial request, without the body
3. The client then waits for a response from the server.

   a. If the server receives a final status code from the backend, then it forwards that to the client, closing the inital connection established in 1.
   b. If the status code is 100-Continue, the request body is sent to the server

4. The client then waits for response from the server
5. if Keep-alive is set, a new request can be repeated from step 2.

On the other hand, prior to version 2.4.48, on step 'a', apache forwards the answer received from the backend, but doesn't close the connection if keep-alive is set.

The change is intended in order to comply to rfc7231#page-35 see https://datatracker.ietf.org/doc/html/rfc7231#page-35
for more details. Actually after step 'a', the server has no way to determine if the next data send from the client is the request body for the previous request or a new request. And thus closing the connection in case of 'a' should avoid request smuggling attacks.

The update is required in order to get TLS 1.3.