Envoy: CONNECT request with IP address as hostname fails with invalid_url

[roelfdutoit]

Description:
If the browser/client is configured to use an explicit HTTPS proxy and the destination is an IP address then envoy fails the connection with a "400 Bad Request" due to a "invalid_url" error.

Logs:

[2020-09-15 20:37:09.669][1608][trace][http] [external/envoy/source/common/http/http1/codec_impl_legacy.cc:632] [C0] onHeadersCompleteBase
[2020-09-15 20:37:09.669][1608][trace][http] [external/envoy/source/common/http/http1/codec_impl_legacy.cc:470] [C0] completed header: key=Host value=10.0.0.1:4443
[2020-09-15 20:37:09.669][1608][trace][http] [external/envoy/source/common/http/http1/codec_impl_legacy.cc:676] [C0] codec entering upgrade mode for CONNECT request.
[2020-09-15 20:37:09.669][1608][trace][http] [external/envoy/source/common/http/http1/codec_impl_legacy.cc:851] [C0] Server: onHeadersComplete size=4
[2020-09-15 20:37:09.669][1608][debug][http] [external/envoy/source/common/http/filter_manager.cc:773] [C0][S6861130327348177454] Sending local reply with details http1.invalid_url
[2020-09-15 20:37:09.669][1608][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1255] [C0][S6861130327348177454] closing connection due to connection close header
[2020-09-15 20:37:09.669][1608][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1311] [C0][S6861130327348177454] encoding headers via codec (end_stream=false):
':status', '400'
'content-length', '11'
'content-type', 'text/plain'
'date', 'Tue, 15 Sep 2020 20:37:09 GMT'
'connection', 'close'

Detail:
I traced it to Url::initialize in url_utility.cc, which uses GURL. The problem is that the GURL parser decodes the "hostname:port" string as a scheme (as also stated on url_utility.cc:65) and that GURL performs a sanity check on the "scheme" to make sure the first character is an alpha. See IsSchemeFirstChar() in google URL url/url_canon_etc.cc:95. In other words an IP address would fail the scheme sanity check.

[mattklein123]

Hmm this does seem like something we should fix somehow but not sure of the RFC details. cc @yanavlasov @dio @alyssawilk who have been looking at similar things recently.

[yanavlasov]

Yes, it looks like a bug. This code is going to be changed very soon. We will keep this bug open to make sure we look into this case.

[alyssawilk]

IPv4 was fixed a ways back. IPv6 was fixed by #13798 so you should be good to go!