Affected version

All

Bug description

Maven support for HTTP proxies was always limited to HTTP (non TLS) proxies. With change in Resolver apache/maven-resolver#746 problem popped out as IT MavenITmng2305MultipleProxiesTest fails. While looking for real reasons, following information has been gathered, and it seems we have several (code and documentation) conflicting things to sort out:

• documentation states "one can have only one active proxy" (in settings.xml), and this is even confirmed by comments on MNG-2305 related issues (in complex/corporate scenarios use of MRM is recommended), BUT this IT exactly tests this, defines 2 proxies, each per protocol. So maybe doco needs to state "one can have only one active proxy per protocol"?
• documentation states that proxy distinct fields protocol, host and port defines URL proto://host:port, in other words HOW the connection is made toward proxy; this is not true
• in reality, Maven never supported TLS proxies (those https://host:port) only http://host:port. In all Maven versions so far this was the the "connection" to proxies (always HTTP, never HTTPS/TLS).
• in reality, the settings/proxies/proxy[]/protocol is used to match remote repository to proxy, by protocol. Today, this is becoming really irrelevant, given HTTP remote repositories are almost never used (and by def they are even blocked), they are all HTTPS.

In real life TLS/HTTPS proxies are becoming a norm in corporate envs. But, right now, the field
settings/proxies/proxy[]/protocol is documented as one, and used for something else.

Related facts:

• new JDK transport does not even support TLS proxies
• ApacheTransporter (former HttpTransporter in mvn3) can be "side configured" using "aether.transport.apache.useSystemProperties" and it will then pick up properties as explained in HttpClientBuilder.

What now?