https://bz.apache.org/bugzilla/show_bug.cgi?id=66499
Bug ID: 66499
Summary: 302 redirects when the :scheme header does not match
the connection type
Product: Apache httpd-2
Version: 2.4.55
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_http2
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]