I’m at a loss, and I’m hoping someone in the community might be able to help me understand a strange situation I’m troubleshooting.
In short: I’m using Kyma, which uses Istio. I am new-ish to both, though familiar with their concepts. I use a Kyma “API Rule”, which in turn uses Istio VirtualServices.
In most testing up until now, requests have worked fine. I can make HTTP/1.1 requests via Postman, and HTTP/2 requests via Insomnia, from my local machine to the Kyma instance.
However, our SAP environment seems to be unable to make requests. The same URL, auth, body, content-type, compression, etc. and a 404 is being returned instead. I am able to reproduce the behavior using Apidog, a Postman/Insomnia-like tool that has experimental HTTP/2 support, but that tool is new to me (was recommended by a colleague who recreated the issue).
I enabled Istio’s debug logs, and looked at the failing vs successful requests. The failing requests seem to have one thing in common: In the istio “:authority” request header, the hostname is duplicated. If the hostname is
xyz.com, successful requests have
xyz.com in the authority pseudo-header, and failed requests have
As a result (I think) in the debug logs, I see:
envoy filter source/extensions/filters/http/alpn/alpn_filter.cc:61 cannot find route entry
What I can’t figure out is: how is that happening?
- Is the client setting these values wrong? Or is it happening somewhere else?
- Is there a way to relax Istio so that it will find the routes when the authority is sent as
- Is there some pre-processing happening in either Istio or Envoy where this
:authoritypseudo-header is being generated / calculated? And if so, is there possibly an issue there where in some cases that value is appended to when it shouldn’t be?
Full technical details with logs etc. here: Some HTTP/2 requests fail with duplicate value in envoy authority request header · Issue #48088 · istio/istio · GitHub – but realizing it is better as a question for this group rather than assuming it’s an Istio bug.