Proxy authentication does not work with vertx client and https endpoint

[shawkins]

Describe the bug

The code is using the generic proxy authentication, but vertx needs the username and password passed to it via the proxy options.

Fabric8 Kubernetes Client version

6.13.3

Steps to reproduce

Use proxy.username and proxy.password with the vertx client

Expected behavior

Proxy authentication should work

Runtime

Kubernetes (vanilla)

Kubernetes API Server version

1.25.3@latest

Environment

Linux

Fabric8 Kubernetes Client Logs

No response

Additional context

No response

[manusa]

Didn't we have a generic proxy (spec) test for all the clients?

[shawkins]

I need to be more specific, the problem appears to be with https handling. Specifically under the covers okhttp is creating the https tunnel starting with a connect request: https://github.com/square/okhttp/blob/06644bb0507873e9a3b89d9107da537f1b140e91/okhttp/src/main/java/okhttp3/internal/connection/RealConnection.java#L444

For the other client types if we are associating the authentication info just with the header, the similar logic they have for this case doesn't pick up the username / password.

[shawkins]

A guide to our proxy scenarios:

End point	Proxy	Autenticated	Tested
http	https	y	n - only Jetty seems to differentiate secure proxies
http	https	n	n - only Jetty seems to differentiate secure proxies
http	http	y	y
http	http	n	n - but should work
https	https	y	n - only Jetty seems to differentiate secure proxies
https	https	n	n - only Jetty seems to differentiate secure proxies
https	http	y	n - this issue. Probably not a high severity because you are still sending unencrypted credentials
https	http	n	n

socks 4/5 are also untested.