- ruby-core - ml.ruby-lang.org

[ruby-core:118569] [Ruby master Misc#20630] Potential optimizations for `NODE_CONST` compilation
by zack.ref＠gmail.com (Zack Deveau) 11 Jul '24

11 Jul '24

Issue #20630 has been reported by zack.ref(a)gmail.com (Zack Deveau). ---------------------------------------- Misc #20630: Potential optimizations for `NODE_CONST` compilation https://bugs.ruby-lang.org/issues/20630 * Author: zack.ref(a)gmail.com (Zack Deveau) * Status: Open ---------------------------------------- ### Description I would like to propose two potential optimizations to the way we currently compile `NODE_CONST` nodes in `compile.c`. I've included commits for each on a related PR. - PR: https://github.com/ruby/ruby/pull/11154 - `NODE_CONST` compilation: [9b6d613](https://github.com/ruby/ruby/commit/9b6d613e19c1132ace64583ac23c94… - `opt_getconstant_path` peephole optimization: [b8ece8c](https://github.com/ruby/ruby/commit/b8ece8ca6e2d60cb7c627927aa89c1… These commits pass `test-all` locally. ### `NODE_CONST` Compilation From what I can tell `NODE_CONST` doesn't appear to follow the conventional use of `popped` found in other similar nodes. For example `NODE_IVAR`, when `popped` (return value not used), will avoid adding the YARV instruction altogether: ```C case NODE_IVAR:{ debugi("nd_vid", RNODE_IVAR(node)->nd_vid); if (!popped) { ADD_INSN2(ret, node, getinstancevariable, ID2SYM(RNODE_IVAR(node)->nd_vid), get_ivar_ic_value(iseq, RNODE_IVAR(node)->nd_vid)); } break; } ``` When compiling a `NODE_CONST` that is `popped`, we instead add either `get_constant` or the optimized `opt_getconstant_path` instruction, followed by adding a `pop`. I've modified it to follow the convention found elsewhere to avoid adding either instruction(s) in cases where we don't need the return value. `test-all` passes locally and I can't think of meaningful side effects (other than we avoid exercising the cache). Please let me know if I'm missing any! ### `opt_getconstant_path` peephole optimization `iseq_peephole_optimize` includes an optimization for `insn -> pop` sequences. Most of the `get_x` instructions are included but we don't appear to include `opt_getconstant_path`. (potentially since it was only recently added in 2022 by @jhawthorn ?) I've included it and attempted to account for any meaningful side effects (here again I can't think of any other than we avoid exercising the cache). Please let me know if I missed any. ### Results `test.rb` ```Ruby NETSCAPE = "navigator" [NETSCAPE, NETSCAPE, NETSCAPE, NETSCAPE] 1 ``` `ruby 3.4.0dev (2024-07-11T19:49:14Z master 6fc83118bb) [arm64-darwin23]` ``` 💾 ➜ ruby --dump insn ./test.rb == disasm: #<ISeq:<main>@./test.rb:1 (1,0)-(3,1)> 0000 putchilledstring "navigator" ( 1)[Li] 0002 putspecialobject 3 0004 setconstant :NETSCAPE 0006 opt_getconstant_path <ic:0 NETSCAPE> ( 2)[Li] 0008 pop 0009 opt_getconstant_path <ic:1 NETSCAPE> 0011 pop 0012 opt_getconstant_path <ic:2 NETSCAPE> 0014 pop 0015 opt_getconstant_path <ic:3 NETSCAPE> 0017 pop 0018 putobject_INT2FIX_1_ ( 3)[Li] 0019 leave ``` `with optimizations` ``` 💾 ➜ ./build/miniruby --dump insn ./test.rb == disasm: #<ISeq:<main>@./test.rb:1 (1,0)-(3,1)> 0000 putchilledstring "navigator" ( 1)[Li] 0002 putspecialobject 3 0004 setconstant :NETSCAPE 0006 putobject_INT2FIX_1_ ( 3)[Li] 0007 leave ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:118524] [Ruby master Bug#20622] irb: invalid byte sequence in UTF-8
by chmaynard (Craig Maynard) 11 Jul '24

11 Jul '24

Issue #20622 has been reported by chmaynard (Craig Maynard). ---------------------------------------- Bug #20622: irb: invalid byte sequence in UTF-8 https://bugs.ruby-lang.org/issues/20622 * Author: chmaynard (Craig Maynard) * Status: Open * ruby -v: ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby $ irb /opt/homebrew/Cellar/ruby/3.3.3/lib/ruby/3.3.0/reline/config.rb:172:in `match': invalid byte sequence in UTF-8 (ArgumentError) next if line.match(/\A\s*#/) ^^^^^^^^ -- https://bugs.ruby-lang.org/

2 3

[ruby-core:117644] [Ruby master Feature#20443] Allow Major GC's to be disabled
by eightbitraptor (Matthew Valentine-House) 11 Jul '24

11 Jul '24

Issue #20443 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Feature #20443: Allow Major GC's to be disabled https://bugs.ruby-lang.org/issues/20443 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open ---------------------------------------- [[Github PR #10598]](https://github.com/ruby/ruby/pull/10598) ## Background Ruby's GC running during Rails requests can have negative impacts on currently running requests, causing applications to have high tail-latency. A technique to mitigate this high tail-latency is Out-of-band GC (OOBGC). This is basically where the application is run with GC disabled, and then GC is explicitly started after each request, or when no requests are in progress. This can reduce the tail latency, but also introduces problems of its own. Long GC pauses after each request reduce throughput. This is more pronounced on threading servers like Puma because all the threads have to finish processing user requests and be "paused" before OOBGC can be triggered. This throughput decrease happens for a couple of reasons: 1. There are few heuristics available for users to determine when GC should run, this means that in OOBGC scenarios, it's possible that major GC's are being run more than necessary. 2. The lack of any GC during a request means that lots of garbage objects have been created and not cleaned up, so the process is using more memory than it should - requiring major GC's run as part of OOBGC to do more work and therefore take more time. This ticket attempts to address these issues by: 1. Provide `GC.disable_major` and its antonym `GC.enable_major` to disable and enable only major GC 2. Provide `GC.needs_major?` as a basic heuristic allowing users to tell when Ruby should run a Major GC. These ideas were originally proposed by @ko1 and @byroot in [this rails issue](https://github.com/rails/rails/issues/50449) Disabling GC major's would still allow minor GC's to run during the request, avoiding the ballooning memory usage caused by not running GC at all, and reducing the time that a major takes when we do run it, because the nursery objects have been cleaned up during the request already so there is less work for a major GC to do. This can be used in combination with `GC.needs_major?` to selectively run an OOBGC only when necessary ## Implementation This PR adds 3 new methods to the `GC` module - `GC.disable_major` This prevents major GC's from running automatically. It does not restrict minors. When `objspace->rgengc.need_major_gc` is set and a GC is run, instead of running a major, new heap pages will be allocated and a minor run instead. `objspace->rgengc.need_major_gc` will remain set until a major is manually run. If a major is not manually run then the process will eventually run out of memory. When major GC's are disabled, object promotion is disabled. That is, no objects will increment their ages during a minor GC. This is to attempt to minimise heap growth during the period between major GC's, by restricting the number of old-gen objects that will remain unconsidered by the GC until the next major. When `GC.start` is run, then major GC's will be enabled, a GC triggered with the options passed to `GC.start`, and then `disable_major` will be set to the state it was in before `GC.start` was called. - `GC.enable_major` This simply unsets the bit preventing major GC's. This will revert the GC to normal generational behaviour. Everything behaves as default again. - `GC.needs_major?` This exposes the value of `objspace->rgengc.need_major_gc` to the user level API. This is already exposed in `GC.latest_gc_info[:need_major_by]` but I felt that a simpler interface would make this easier to use and result in more readable code. eg. ```ruby out_of_band do GC.start if GC.needs_major? end ``` Because object aging is disabled when majors are disabled it is recommended to use this in conjunction with `Process.warmup`, which will prepare the heap by running a major GC, compacting the heap, and promoting every remaining object to old-gen. This ensures that minor GC's are running over the smallets possible set of young objects when `GC.disable_major` is true. ## Benchmarks We ran some tests in production on Shopify's core monolith over a weekend and found that: **Mean time spent in GC, as well as p99.9 and p99.99 GC times are all improved.** <img width="1000" alt="Screenshot 2024-04-22 at 16 41 49" src="https://github.com/ruby/ruby/assets/31869/6cff5b11-2e21-40c1-bb84-d994e0e17…"> **p99 GC time is slightly higher.** <img width="1000" alt="Screenshot 2024-04-22 at 16 44 55" src="https://github.com/ruby/ruby/assets/31869/dc645cbe-9495-46f0-8485-24e790c42…"> We're running far fewer OOBGC major GC's now that we have `GC.needs_major?` than we were before, and we believe that this is contributing to a slightly increased number of minor GC's. raising the p99 slightly. **App response times are all improved** We see a 9% reduction in average and p99 response times when compared against standard GC (4% p99.9 and p99.99). <img width="1000" alt="Screenshot 2024-04-22 at 16 55 53" src="https://github.com/ruby/ruby/assets/31869/8a80c102-1564-4bc9-ba44-6e9a8b85f…"> This drops slightly to an 8% reduction in average and p99 response times when compared against standard OOBGC (3.59 p99.9 and 4% p99.99) <img width="1000" alt="Screenshot 2024-04-22 at 16 56 10" src="https://github.com/ruby/ruby/assets/31869/1baef7ea-0155-4ff9-8ba4-a967b7574…"> -- https://bugs.ruby-lang.org/

7 24

[ruby-core:118566] [Ruby master Bug#9115] Logger traps all exceptions; breaks Timeout
by jeremyevans0 (Jeremy Evans) 11 Jul '24

11 Jul '24

Issue #9115 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed I merged https://github.com/ruby/logger/pull/37 to fix this issue. ---------------------------------------- Bug #9115: Logger traps all exceptions; breaks Timeout https://bugs.ruby-lang.org/issues/9115#change-109088 * Author: cphoenix (Chris Phoenix) * Status: Closed * Assignee: sonots (Naotoshi Seo) * ruby -v: ruby 2.0.0p247 (2013-06-27) [i386-mingw32] ---------------------------------------- Line 577-579 of logger.rb rescue Exception => ignored warn("log writing failed. #{ignored}") end Thus, when the system times out in the middle of writing a log message, it warns "log writing failed. execution expired" and just keeps right on running. This is true in 1.9.3 as well. I haven't looked at older versions. Pardon me while I go grep "rescue Exception" in the entire Ruby codebase, and see whether I can reliably use Timeout at all... OK, you might check out C:\Ruby200\lib\ruby\gems\2.0.0\gems\activerecord-3.2.13\lib\active_record\railties\databases.rake All the other "rescue Exception" seem to re-raise it, except maybe C:\Ruby200\lib\ruby\2.0.0\xmlrpc\server.rb and C:\Ruby200\lib\ruby\gems\2.0.0\gems\activesupport-3.2.13\lib\active_support\callbacks.rb -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118539] [Ruby master Bug#20626] `defined?(@ivar)` should return nil when `@iv` can raise on Ractor
by ko1 (Koichi Sasada) 11 Jul '24

11 Jul '24

Issue #20626 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Bug #20626: `defined?(@ivar)` should return nil when `@iv` can raise on Ractor https://bugs.ruby-lang.org/issues/20626 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Return `nil` for `defined?(@ivar)` on some cases with Ractor. ## Background It is not allowed to get instance variables from an object if 1. the object is shareable 2. and the instance variable refers to an unshareable object like the following code: ```ruby class Ractor def setup_iv @iv = [] end def get_iv = @iv end R = Ractor.new{} R.setup_iv p R.get_iv #=> [] Ractor.new{|;iv| p R.get_iv #=> can not access instance variables of shareable objects from non-main Ractors (Ractor::IsolationError) }.take ``` I believe nobody use ivars on Ractor objects. However it is used on classes and modules (shareable objects) casually use it. ```ruby class C @iv = [] def self.iv = @iv end p C.iv #=> [] Ractor.new{ p C.iv #=> can not get unshareable values from instance variables of classes/modules from non-main Ractors (Ractor::IsolationError) }.take ``` Current behavior on `defined?` with such ivars is strange because: * Case1: raising an error ```ruby class C @iv1 = [] def self.defined_iv1 = defined?(@iv1) end Ractor.new{ p C.defined_iv1 #=> can not get unshareable values from instance variables of classes/modules from non-main Ractors (Ractor::IsolationError) }.take ``` * Case2: incorrect result ```ruby class C # @iv2 is not defined def self.defined_iv2 = defined?(@iv2) end Ractor.new{ p C.defined_iv2 #=> "instance-variable" }.take ``` This is because current implementation uses accessing ivars on such cases. It seems a simple bug. ## Proposal In other words, we can't use such ivars on Ractors on Case1. So that returning `nil` on Case1 and Case2 reasonable. ```ruby class C @iv1 = [] def self.defined_iv1 = defined?(@iv1) # @iv2 is not defined def self.defined_iv2 = defined?(@iv2) @iv3 = 42 # refers to shareable object def self.defined_iv2 = defined?(@iv3) end p C.defined_iv1 #=> "instance-variable" p C.defined_iv2 #=> "instance-variable" Ractor.new{ p C.defined_iv1 # current: can not get unshareable values from instance variables of classes/modules from non-main Ractors (Ractor::IsolationError) # proposed: nil because it is not accessible from here p C.defined_iv2 # current: "instance-variable" # proposed: nil p C.defined_iv3 #=> "instance-variable" because we can access it }.take ``` ## Usage `FileUtils` uses `defined?(@non_existing_ivar)` technique to configure its behavior so I found the Case2. https://github.com/ruby/fileutils/blob/master/lib/fileutils.rb#L2501 ## Implementation https://github.com/ruby/ruby/pull/11141 We need to more modification to YJIT. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118553] [Ruby master Bug#9115] Logger traps all exceptions; breaks Timeout
by sonots (Naotoshi Seo) 11 Jul '24

11 Jul '24

Issue #9115 has been updated by sonots (Naotoshi Seo). Sorry to be late. Because I've been a bit busy lately, so I'll leave this to Jeremy Evans. ---------------------------------------- Bug #9115: Logger traps all exceptions; breaks Timeout https://bugs.ruby-lang.org/issues/9115#change-109074 * Author: cphoenix (Chris Phoenix) * Status: Assigned * Assignee: sonots (Naotoshi Seo) * ruby -v: ruby 2.0.0p247 (2013-06-27) [i386-mingw32] ---------------------------------------- Line 577-579 of logger.rb rescue Exception => ignored warn("log writing failed. #{ignored}") end Thus, when the system times out in the middle of writing a log message, it warns "log writing failed. execution expired" and just keeps right on running. This is true in 1.9.3 as well. I haven't looked at older versions. Pardon me while I go grep "rescue Exception" in the entire Ruby codebase, and see whether I can reliably use Timeout at all... OK, you might check out C:\Ruby200\lib\ruby\gems\2.0.0\gems\activerecord-3.2.13\lib\active_record\railties\databases.rake All the other "rescue Exception" seem to re-raise it, except maybe C:\Ruby200\lib\ruby\2.0.0\xmlrpc\server.rb and C:\Ruby200\lib\ruby\gems\2.0.0\gems\activesupport-3.2.13\lib\active_support\callbacks.rb -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117431] [Ruby master Misc#20407] Question about applying encoding modifier to an interpolated Regexp
by andrykonchin (Andrew Konchin) 11 Jul '24

11 Jul '24

Issue #20407 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #20407: Question about applying encoding modifier to an interpolated Regexp https://bugs.ruby-lang.org/issues/20407 * Author: andrykonchin (Andrew Konchin) * Status: Open ---------------------------------------- I am wondering how Regexp encoding modifiers (u, s, e, n) interfere in encoding negotiation of interpolated Regexp literal. Examples #1 ```ruby # encoding: us-ascii # Unicode: Ф - U+0424 # windows-1251: Ф - 0xD4 # without encoding modifier puts /a #{ "\xd4".force_encoding("windows-1251") } c/.encoding # Windows-1251 puts /a #{ "b".encode("windows-1251") } c/.encoding # US-ASCII puts /a #{ "\u0424".force_encoding("UTF-8") } c/.encoding # UTF-8 puts /a #{ "\xc2\xa1".b } c/.encoding # ASCII-8BIT # with encoding modifier puts /a #{ "\xd4".force_encoding("windows-1251") } c/e.encoding # Windows-1251 puts /a #{ "b".encode("windows-1251") } c/e.encoding # EUC-JP puts /a #{ "\u0424".force_encoding("UTF-8") } c/e.encoding # UTF-8 puts /a #{ "\xc2\xa1".b } c/e.encoding # ASCII-8BIT # string literals concatenation puts ("a" + "\xd4".force_encoding("windows-1251") + "c").encoding # Windows-1251 puts ("a" + "b".encode("windows-1251") + "c").encoding # US-ASCII puts ("a" + "\u0424".force_encoding("UTF-8") + "c").encoding # UTF-8 puts ("a" + "\xc2\xa1".b + "c").encoding # ASCII-8BIT ``` Example #2 ```ruby # encoding: utf-8 # windows-1251: Ф - 0xD4 # unicode: Ф - U+0424 # without encoding modifier puts /a #{ "\xd4".force_encoding("windows-1251") } c/.encoding # Windows-1251 puts /a #{ "b".encode("windows-1251") } c/.encoding # US-ASCII puts /a #{ "\u0424".force_encoding("UTF-8") } c/.encoding # UTF-8 puts /a #{ "\xc2\xa1".b } c/.encoding # ASCII-8BIT # with encoding modifier puts /a #{ "\xd4".force_encoding("windows-1251") } c/e.encoding # Windows-1251 puts /a #{ "b".encode("windows-1251") } c/e.encoding # EUC-JP puts /a #{ "\u0424".force_encoding("UTF-8") } c/e.encoding # UTF-8 puts /a #{ "\xc2\xa1".b } c/e.encoding # ASCII-8BIT # string literals concatenation puts ("a" + "\xd4".force_encoding("windows-1251") + "c").encoding # Windows-1251 puts ("a" + "b".encode("windows-1251") + "c").encoding # UTF-8 puts ("a" + "\u0424".force_encoding("UTF-8") + "c").encoding # UTF-8 puts ("a" + "\xc2\xa1".b + "c").encoding # ASCII-8BIT ``` In the examples above the `e` modifier changes Regexp's encoding only in one case when Regexp's encoding would be `US-ASCII` without the modifier: ```ruby # encoding: us-ascii puts /a #{ "b".encode("windows-1251") } c/.encoding # US-ASCII puts /a #{ "b".encode("windows-1251") } c/e.encoding # EUC-JP ``` ```ruby # encoding: utf-8 puts /a #{ "b".encode("windows-1251") } c/.encoding # US-ASCII puts /a #{ "b".encode("windows-1251") } c/e.encoding # EUC-JP ``` And the `e` modifier doesn't change Regexp's final encoding in all the other cases either Regexp's encoding without modifier is a file source encoding or `ASCII-8BIT`. Looking at the following example: ```ruby # encoding: us-ascii # without modifier p /\xc2\xa1 #{ "a" }\xc2\xa1/.encoding # ASCII-8BIT p /a #{ "\xc2\xa1".force_encoding("EUC-JP") } b/.encoding # EUC-JP p /a #{ "\xc2\xa1".b } b/.encoding # ASCII-8BIT # with modifier p /\xc2\xa1 #{ "a" }\xc2\xa1/e.encoding # EUC-JP p /a #{ "\xc2\xa1".force_encoding("EUC-JP") } b/e.encoding # EUC-JP p /a #{ "\xc2\xa1".b } b/e.encoding # ASCII-8BIT ``` we can notice that the `e` modifier change `ASCII-8BIT` to `EUC-JP` in the first case but doesn't in the third one. So I assume that the `e` modifier could be applied to the Regexp fragments (`\xc2\xa1` and `\xc2\xa1`) before encoding negotiation and not to the whole result after negotiation. Could you please clarify how it works? -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118383] [Ruby master Bug#20593] `Kernel#format` emits a `too many arguments for format string` warning when called with keyword arguments and none are used
by byroot (Jean Boussier) 11 Jul '24

11 Jul '24

Issue #20593 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20593: `Kernel#format` emits a `too many arguments for format string` warning when called with keyword arguments and none are used https://bugs.ruby-lang.org/issues/20593 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `Kernel#format` emits a warning when too many arguments are passed. It does so for postional arguments, which make sense, as it could be indicative of a bug: ```ruby $VERBOSE = true format("%s", 1, 2) # warning: too many arguments for format string ``` And doesn't for keyword arguments, as it's much less likely to be a bug: ```ruby $VERBOSE = true format("%{a}s", a: 1, unused: 2) # no warning ``` However it does emit a warning when passing keyword arguments, if none are used: ```ruby $VERBOSE = true format("test", unused: 2) # warning: too many arguments for format string ``` Which I believe is a bug, as it's common for `format` to take a user provided string to allow for safe interpolation, but with no intention to enforce any of the arguments to be interpolated. So I think that last case shouldn't emit a warning. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118496] [Ruby master Bug#20618] ruby uses 1/2 (8 out of 16) cores for 16 ractors
by skorobogatydmitry (Dmitry Skorobogaty) 11 Jul '24

11 Jul '24

Issue #20618 has been reported by skorobogatydmitry (Dmitry Skorobogaty). ---------------------------------------- Bug #20618: ruby uses 1/2 (8 out of 16) cores for 16 ractors https://bugs.ruby-lang.org/issues/20618 * Author: skorobogatydmitry (Dmitry Skorobogaty) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- According to `top`, the below code uses 7/16 cores (700%) of my AMD Ryzen 7 5800HS: ``` #!/usr/bin/env ruby 16.times { Ractor.new { 10_000.downto(1) { |i| 100_000.downto(1) { |j| i * j } } } } sleep 30 ``` The same code occupies all 16 cores on `ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]` The problem reproduces on `ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [x86_64-linux]` (ruby from the latest docker image). -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118538] [Ruby master Feature#16482] net/http should support TLS connection to proxies
by hsbt (Hiroshi SHIBATA) 11 Jul '24

11 Jul '24

Issue #16482 has been updated by hsbt (Hiroshi SHIBATA). Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Feature #16482: net/http should support TLS connection to proxies https://bugs.ruby-lang.org/issues/16482#change-109057 * Author: xformer (Frank Schwab) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Right now net/http forces the user to use a clear text connection to a proxy. This massively reduces security as the user is forced to sent proxy authentication data in the clear. A proxy is specified in net/http like this: ``` proxy_addr = 'your.proxy.host' proxy_port = 8080 proxy_user = 'aProxyUser' proxy_pwd = 'aProxyPassword' Net::HTTP.new('example.com', nil, proxy_addr, proxy_port, proxy_user, proxy_pwd).start { |http| # always proxy via your.proxy.addr:8080, user 'aProxyUser', password 'aProxyPassword' } ``` There is no scheme present in the 'proxy_addr' variable. In the code of Net::HTTP::new the proxy connection is opened via a TCP socket, not via HTTP or HTTPS. As this considerably weakens security I would like to suggest that it should be made possible to specify that the connection to the proxy is done through a TLS connection. Maybe there could be a use_ssl parameter or the like. Note that this issue is not about the connection that is routed through the proxy but about the connection to the proxy itself. -- https://bugs.ruby-lang.org/

1 0