What were you trying to do that didn't work?

The CVE-2024-38477 fix exposes a mod_proxy_http2 bug that can now result in request failures whenever a proxy connection is re-attempted. This scenario always hits the "AH00898: URI has no hostname" error check added by the CVE fix. This is fixed upstream in 2.4.60+ by https://github.com/apache/httpd/commit/4d3a308014be26e5407113b4c827a1ea2882bf38 so we need to backport this.

What is the impact of this issue to you?

Random failures.

Please provide the package NVR for which the bug is seen:

2.4.37-65.module+el8.10.0+22069+b47f5c72.1

How reproducible is this bug?:

Very.

Steps to reproduce

1. Set up a simple h2 proxy pass with a destination using a short KeepAliveTimeout. This can be self referential in a single httpd config:

   Protocols h2 h2c http/1.1
   KeepAlive On
   KeepAliveTimeout 2
   ProxyPass /foobar h2c://127.0.0.1:81/
   
   Listen 81
   <VirtualHost *:81>
   </VirtualHost>
   

2. This will reproduce most consistently if you also use an mpm config with a single process:

   LoadModule mpm_worker_module modules/mod_mpm_worker.so
   <IfModule mpm_worker_module>
           ThreadLimit            30
           ServerLimit            1
           StartServers           1
           MinSpareThreads        5
           MaxSpareThreads        30
           ThreadsPerChild        30
           MaxRequestWorkers      30
           MaxConnectionsPerChild 0
   </IfModule>
   

3. Send a request that will be proxied, wait for the backend destination keepalive timeout to pass then send another request. A simple one liner testing the above config:

   $ curl localhost/foobar; sleep 3; curl localhost/foobar
   

Expected results

The default welcome page is returned without issue.

Actual results

The second request receives a 503 with the following error:

[Wed Sep 11 12:35:25.133153 2024] [proxy:error] [pid 30682:tid 140183244572416] [client ::1:51798] AH00898: URI has no hostname: / returned by /foobar

A workaround can be to switch to plain http proxying or set disablereuse on the proxy worker or to set smax=0 with a ttl that is smaller than the backend destination's typical keepalive timeout so httpd will initiate connection closes before the backend (that may avoid most issue occurrences but there may still be some retry occurrences reaching this issue if a connection is closed out by the backend for some other reason prior to the ttl/keepalive timeout):

ProxyPass /foobar h2c://127.0.0.1:81/ smax=0 ttl=1