Inconsistent default proxy configuration settings for http clients #4745
Description
Describe the bug
When using different HTTP clients for AWS Clients, the behaviour of whether proxy configuration is picked up differs.
When I specify the java network proxy system properties of -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=1234, then the behaviour seen with ApacheHttpClient is that the proxy settings are applied and honoured. However the behaviour seen with NettyNioAsyncHttpClient is that the proxy settings are not applied or honoured.
This leads to behaviour where when swapping from the default setup of a synchronous client to an asynchronous client (for example swapping between an SqsClient to an SqsAsyncClient), proxy settings are no longer applied by default, which is confusing and inconsistent.
Expected Behavior
I expect that when constructing a default synchronous and a default asynchronous client, that they would have the same default behaviour with regards to proxy settings. I encountered this specific issue when working with SQS clients, but would affect other clients.
Based on the documentation of how to configure the Netty client I would expect that the system properties would automatically apply, since it says "The equivalent Java system properties for the proxy configuration are shown in the following command line snippet.".
Current Behavior
The behaviour of a default synchronous client is that proxy settings are read from the system properties and envrionment variables.
The behaviour of a default asynchronous client is that proxy settings are not read from the system properties and environment variables, and no proxy configuration is defined.
Reproduction Steps
Set the following System Properties: -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=1234.
Create an instance of the SqsClient and an instance of the SqsAsyncClient.
SqsClient syncClient = SqsClient.builder().build();
syncClient.listQueues(); //Goes through proxy
SqsAsyncClient asyncClient = SqsAsyncClient.builder().build();
asyncClient.listQueues(); //Does not go through proxy
Inspecting the relevant instances in the debugger, you can see the ApacheHttpClient has a ProxyConfiguration set, and the NettyNioAsyncHttpClient does not.
Possible Solution
This seems to be because of differing default behaviour in how ProxyConfiguration is initialised in the respective DefaultBuilders.
ApacheHttpClient initialises an default ProxyConfiguration.
NettyNioAsyncHttpClient initialises a null ProxyConfiguration.
This will also affect the other two clients (UrlConnectionHttpClient and AwsCrtAsyncHttpClient) as they default a null ProxyConfiguration.
Defaulting a ProxyConfiguration for these clients would make behaviour consistent, where proxy configuration settings defined in either system properties or envrionment variables will be read and applied if they exist, and if not no proxy will be applied.
A potential issue with this though is this could impact users who have these proxy settings applied to their environment or system currently, and they do not want to use them. However I would argue that itself is a misconfiguration.
Additional Information/Context
This bug is easily worked around by configuring the underlying client with a ProxyConfiguration, but this is not obvious and leads to alot of time debugging why proxy settings are not being picked up.
AWS Java SDK version used
2.21.12,2.21.38
JDK version used
17.0.9
Operating System and version
MacOS 14.1.2