Greetings! I observed that after upgrading httpd from 2.4.54 to 2.4.55, my server has started to 302 requests. My topology is that I have haproxy in front of httpd, which is in front of php-fpm. haproxy is terminating TLS, but it does set the :scheme header to https when passing the request to httpd. I observe that httpd is then redirecting with 302. However, from the user's perspective, they *did* use an https:// scheme when they made the request to haproxy. Thus, this results in a redirect loop. I noticed a note in the changelog that seemed relevant for this, and I found the related commit and a comment in the code: https://github.com/icing/mod_h2/commit/eef92aa372922f8f4491e9f58d327e6762de626d#diff-fb0096c49677980d95821ee43f691777ce0645add49981d04c542b92980ea533R307-R308 When I read RFC 7540, it doesn't read to me like this is the correct behavior: https://www.rfc-editor.org/rfc/rfc7540.html The ":scheme" pseudo-header field includes the scheme portion of the target URI ([RFC3986], Section 3.1). ":scheme" is not restricted to "http" and "https" schemed URIs. A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services. In my case, where haproxy is in front of httpd, isn't it correct that the "target URL" does have an https scheme? Isn't it then correct for this header to be "https" even though the connection is not TLS? I'm not an expert at http/2, so please excuse any misunderstandings I may have.
For what it's worth, I did find an haproxy issue from some years ago where the meaning of this header was debated in the context of a proxy that strips TLS: https://github.com/haproxy/haproxy/issues/77
Yeah while not *technically* a bug this appears to be an unexpected behavior change for cases where Apache is fronted by a reverse proxy handling TLS termination. Among other things, this causes the value of the REQUEST_URI variable sent by mod_proxy_fcgi to be different from versions of Apache prior to 2.4.55.
Fixed in r1909769 and proposed to backport to 2.4.x
(In reply to Stefan Eissing from comment #3) > Fixed in r1909769 and proposed to backport to 2.4.x This fix is actually for bz 66537 only?
No, addresses other bugs as well where I also added a comment. Wrong way?