Add support for https proxies

[ag-TJNII]

Describe the feature

Ruby 3.4 added support for https proxies in Net::HTTP:

• https://bugs.ruby-lang.org/issues/16482
• implement talking SSL to the proxy too ruby/net-http#55

It would be useful to use this to add support for https:// http_proxy arg URLs.

Use Case

This will be needed in environments where a proxy is required to reach the AWS APIs, and the proxy itself requires TLS.

Proposed Solution

Seahorse net_http/connection_pool.rb has a nice http_proxy_parts function that builds out the args so, ignoring compatibility, this should be as simple as adding a 6th, boolean value when http_proxy.scheme == 'https'

Other Information

The main case that makes this a non-trivial implementation is what to do when a user is on a version of Ruby that doesn't support p_use_ssl, but passes a https proxy.

Ruby version	Proxy scheme	Behavior
< 3.4	http	Success
>= 3.4	http	Success
< 3.4	https	ArgumentError
>= 3.4	http	Success

Without special handling the Argument Error will be wrong number of arguments (given 8, expected 1..7) from Net::HTTP.new or something similar but not really useful to the end user.

Given how fresh this support is I recommend detecting this scenario and providing a clear error about support.

On the other hand, the current error is Seahorse::Client::NetworkingError: end of file reached (Seahorse::Client::NetworkingError), which is also opaque, but at least that doesn't look like a code bug.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

SDK version used

3, latest

Environment details (OS name and version, etc.)

N/A

[mullermp]

Thanks for opening a feature request. This seems perfectly valid. An easy way to do this is to check the method arity or ruby version.

[ag-TJNII]

An easy way to do this is to check the method arity or ruby version.

I was planning on catching the ArgumentError and rethrowing with a descriptive error:

ag-TJNII@61a23c4#diff-09033f621f14d5b1807258f222dfe8cdea8f99caefa6fe77e558378c2570a840R297-R306

Is that acceptable or would you prefer a different check?

[ag-TJNII]

I'm holding off on opening a MR with my proposed changes due to ruby/net-http#212.

I'm also concerned that ruby/net-http#209 will be an issue, as the fact that none of the SSL options the SDK constructor provides will apply to the proxy connection may confuse users, and I think it's likely that the API to set the proxy SSL settings will require refactoring the http_proxy_parts pattern.

Anyway, I don't think upstream maturity is at the needed level to resolve this today.

[ag-TJNII]

After a whole day of debugging I've come to the conclusion that the upstream support that triggered this issue is broken, and it looks like there's some deep core library gaps needed to enable this, through the Net::HTTP stdlib gem and into the OpenSSL gem. Looking at the timelines on related issues I'm not optimistic this will be resolved before 2027.

So, while I want this and I think it should be added, I don't think it can be added today without heavy bespoke implementing in this gem. I'm going to close it as a "CAN'T-DO", but I think it should be reopened once the OpenSSL gem supports nesting sockets and the Net::HTTP issues are ironed out.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

[mullermp]

That makes sense. Thank you for closing. May I ask why you are using an https proxy? They are typically http only.

[ag-TJNII]

Compliance requirements. I'm not 100% in the loop on as the proxy isn't my responsibility. My understanding is we're taking a strict "everything must be TLS" interpretation, which does make sense to protect the proxy auth and connect handshaking.