Default Envoy config no longer works

[phlax]

description

sometime ago we switched the default Envoy config (eg included in the docker images) from pointing to google.com -> www.envoyproxy.io

there were a couple of reasons for shifting - one was that the google example stopped working (due to CSP i think) - where you request an http page that proxies to an https page

at the time proxying to the www.envoyproxy.io domain worked fine

in recent tests i noticed that this is no longer the case - or at least more often than not it doesnt work - sometimes it does work

basically when you request over http you get a proxied response to 301 redirect to https

im not sure if something has changed in the website handling of headers, or whether the headers that envoy sends has changed - but either way it no longer works - wierdly it occasionally does work

this can be tested as follows

$ docker run -p 10000:10000 -d --rm envoyproxy/envoy-dev:latest 
bb9028e3a5f85637e6cece640a7caab456987ac5d99279277c932258eb2d4290
$ curl http://localhost:10000
Redirecting to https://www.envoyproxy.io/
$ docker kill bb902

relevant config is here https://github.com/envoyproxy/envoy/blob/main/configs/envoyproxy_io_proxy.yaml

[phlax]

cc @alyssawilk @mattklein123

[alyssawilk]

huh. think we should just switch back to google? I'm not sure what prompted the change but we have to use google for the equivalent HTTP/3 config (since envoyproxy doesn't have that turned up) so it'd both work and be consistent

[phlax]

think we should just switch back to google?

preferably not - apart from anything else it would be good to know why it doesnt work

I'm not sure what prompted the change

2 reasons iirc

• making things less vendor specific - ie less lyft/google etc
• it no longer worked - or at least the initial request worked - but you got a big borked overlay and streaming errors in browser console

but we have to use google for the equivalent HTTP/3 config

hmm - i guess in that case its necessary - but in a way it would be good if we could point it to a neutral reference server

[phlax]

...to a neutral reference server

or maybe a smiley welcome page on something like http3.envoyproxy.io that was http3 enabled

[phlax]

cloudflare has quic/http3 support https://blog.cloudflare.com/http3-the-past-present-and-future/ so we could do it with that

[phlax]

checking this further...

there is an http3 downstream - which proxies to envoy - which i struggled to get working - but even if i had i guess it will hit the same issue raised here

there is an http3 upstream - which works (doesnt even bork wierdly) proxying via http3

as an aside it would be v good to get some http3 sandboxes set up

im gonna mark this high priority - because the docs and docker image are kinda broken - and its a blocker for building system packages #16899

[phlax]

before we fix this @alyssawilk it would be good to add xfailing test/s

#17145 is related but i think possibly we just want to test all of the configs in the /configs dir to ensure they work as expected

ill do some testing and try and figure out a way forward

[phlax]

im not sure if this has been fixed, or if something changed upstream - it was always a flake in the sense that sometimes it worked and sometimes not - but my understanding was that it wouldnt be fixed until #17070 landed

i have tested the default config again with the current envoyproxy/envoy-dev:latest image and now it never fails