See Why is Envoy operating on X-Forwarded-Proto instead of :scheme or vice-versa? for more details. The :scheme header will be used by Envoy over x-forwarded-proto where the URI scheme is wanted, for example serving content from cache based on the :scheme header rather than X-Forwarded-Proto, or setting the scheme of redirects based on the scheme of the original URI. This default behavior can be overridden via the scheme_header_transformation This is the only scheme validation Envoy performs as it avoids a HTTP/1.1-specific privledge escalation attack for edge Envoys 1 which doesn’t have a comparable vector for HTTP/2 and above 2.Ģ) From the value of the x-forwarded-proto header after sanitization (to valid x-forwarded-proto from trusted downstreams, otherwise based on downstream encryption level). An invalid (not “http” or “https”) scheme, or an https scheme over an unencrypted connection will result in Envoy rejecting the request. It should always be available to filters, and should be forwarded upstream for HTTP/2 and HTTP/3, where x-forwarded-proto will be sent for HTTP/1.1.įor HTTP/2, and HTTP/3, incoming :scheme headers are trusted and propogated through upstream.įor HTTP/1, the :scheme header will be setġ) From the absolute URL if present and valid. Envoy will always set the :scheme header while processing a request.
0 kommentar(er)
