async-http-client
async-http-client copied to clipboard
HTTPClient.configuration should expose the configuration set
For some reason, HTTPClient hides the configuration that was used to configure it from the user. We shouldn't do that.
I agree with @weissi 's point of view. Since the configuration of HTTPClient.shared is currently hidden, it is impossible to modify certain properties of configuration when using .shared. Was this intentional by design? I want to restrict redirects for HTTP status 302, but this limitation forces me to abandon .shared, which is quite frustrating.
I agree with @weissi 's point of view. Since the configuration of
HTTPClient.sharedis currently hidden, it is impossible to modify certain properties ofconfigurationwhen using.shared. Was this intentional by design? I want to restrict redirects forHTTP status 302, but this limitation forces me to abandon.shared, which is quite frustrating.
So it is by design that it won't let you modify the global config (that'd be dangerous as it's shared) but of course it's bad that it has important global config. The fix to this is #392 .
A separate bug (the one I filed here) is that AHC currently doesn't even let you read the configuration it has :|...
In addition to allowing global configuration to be readable, I believe the global configuration for HTTPClient should not include redirectConfiguration and decompression. Alternatively, it should allow modifications to redirectConfiguration and decompression on a per-request basis.
In addition to allowing global configuration to be readable, I believe the global configuration for HTTPClient should not include redirectConfiguration and decompression. Alternatively, it should allow modifications to redirectConfiguration and decompression on a per-request basis.
Agreed, I don't see a reason to have any global-only configuration. Everything that's configurable globally only means people need to migrate from HTTPClient.shared and then they're immediately forced to manage manual lifecycles (or incur performance overheads constantly starting/stopping HTTPClients which throws away the connection pool and TLSContext).
FWIW, that's pretty what #392 proposes.