Some HTTP/2 requests fail with comma-separated values in ':authority' pseudo-header

Networking
1

Hi all,

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 xyz.com,xyz.com.

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 xyz.com,xyz.com?
  • Is there some pre-processing happening in either Istio or Envoy where this :authority pseudo-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.

2

Hi all,

Confirmed that this appears to be an issue in the Envoy proxy used by Istio:

Any client that sends both the :authority pseudo-header and the Host header will run into this problem with Envoy it seems, as Envoy will concatenate the :authority field which winds up in an authority that Istio then matches on and doesn’t find any routes for.

The only workaround in the interim is to see if we can coax HTTP/2 clients into not sending both headers with their request.