December 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:115430] [Ruby master Bug#20012] Fix keyword splat passing as regular argument
by jeremyevans0 (Jeremy Evans) 07 Dec '23

07 Dec '23

Issue #20012 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #20012: Fix keyword splat passing as regular argument https://bugs.ruby-lang.org/issues/20012 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-12 master 60e19a0b5f) [x86_64-openbsd] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Since Ruby 3.0, Ruby has passed a keyword splat as a regular argument in the case of a call to a Ruby method where the method does not accept keyword arguments, if the method call does not contain an argument splat: ```ruby def self.f(obj) obj end def self.fs(*obj) obj[0] end h = {a: 1} f(**h).equal?(h) # Before: true; After: false fs(**h).equal?(h) # Before: true; After: false a = [] f(*a, **h).equal?(h) # Before and After: false fs(*a, **h).equal?(h) # Before and After: false ``` The fact that the behavior differs when passing an empty argument splat makes it obvious that something is not working the way it is intended. The fact that the hash is copied for C methods also makes it obvious. Ruby 2 always copied the keyword splat hash, and I think that is the expected behavior in Ruby 3. This bug is because of a missed check in setup_parameters_complex. If the keyword splat passed is not mutable, then it points to an existing object and not a new object, and therefore it must be copied. I did not bisect to find the commit that introduced the problem, but this seems likely to be something I introduced during keyword argument separation. I'm surprised that this has not been filed as a bug sooner. Maybe it just rarely comes up in practice, and I only discovered it recently. Possibly, other developers that may have discovered this may have decided against submitting this as an issue, as we have had specs for two years that give the impression that the broken behavior was expected. I've submitted a pull request to fix this: https://github.com/ruby/ruby/pull/8970 -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115645] [Ruby master Bug#20047] ConditionVariable#wait has spurious wakeups from signal traps
by Eregon (Benoit Daloze) 07 Dec '23

07 Dec '23

Issue #20047 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #20047: ConditionVariable#wait has spurious wakeups from signal traps https://bugs.ruby-lang.org/issues/20047 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-27T17:17:52Z master cc05a60c16) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby Signal.trap("INT") { p :SIGINT } Thread.new do sleep 0.6 `kill -INT #{$$}` end m, cv = Mutex.new, ConditionVariable.new m.synchronize do r = ARGV[0] ? cv.wait(m, 2) : cv.wait(m) p ["ConditionVariable#wait returned", r] end ``` The above program should hang on `.wait` and not return. That's the behavior on TruffleRuby and JRuby, but not on CRuby, where `.wait` wakes up spuriously. ``` $ ruby -v spurious_cv.rb ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", 1] $ ruby -v spurious_cv.rb truffleruby 23.1.1, like ruby 3.2.2, Oracle GraalVM Native [x86_64-linux] :SIGINT # hangs as expected $ ruby -v spurious_cv.rb jruby 9.4.5.0 (3.1.4) 2023-11-02 1abae2700f OpenJDK 64-Bit Server VM 17.0.8+7 on 17.0.8+7 +jit [x86_64-linux] :SIGINT # hangs as expected ``` When given an argument, it should wait 2 seconds. But on CRuby it wakes up spuriously: ``` $ ruby -v spurious_cv.rb timeout ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", 0] $ ruby -v spurious_cv.rb timeout truffleruby 23.1.1, like ruby 3.2.2, Oracle GraalVM Native [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", #<ConditionVariable:0x188>] $ ruby -v spurious_cv.rb timeout jruby 9.4.5.0 (3.1.4) 2023-11-02 1abae2700f OpenJDK 64-Bit Server VM 17.0.8+7 on 17.0.8+7 +jit [x86_64-linux] :SIGINT ["ConditionVariable#wait returned", #<Thread::ConditionVariable:0x482ba4b1>] ``` `ConditionVariable#wait` needs to be interrupted to execute the signal handler, which does `{ p :SIGINT }` on the main thread. However, `ConditionVariable#wait` should automatically be restarted internally after that, with the remaining timeout. That is what I think is the bug in CRuby. While it's good practice to have a loop around ConditionVariable#wait (at least when there is no timeout), it still seems highly unexpected in a high-level language like Ruby to have ConditionVariable#wait return when neither ConditionVariable#{signal,broadcast} are used (i.e., spurious wakeups). Also adding a loop is non-trivial for the case where a timeout argument is passed, as then one needs to manually account the remaining timeout instead of letting ConditionVariable#wait do its job correctly. And also need to check that if ConditionVariable#wait returns nil then one should break the loop, which is quite error-prone. Instead of just using `cv.wait(mutex, timeout)` when it works correctly. From https://github.com/ruby-concurrency/concurrent-ruby/issues/1015 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114722] [Ruby master Bug#19877] Non intuitive behavior of syntax only applied to literal value
by tompng (tomoya ishida) 07 Dec '23

07 Dec '23

Issue #19877 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19877: Non intuitive behavior of syntax only applied to literal value https://bugs.ruby-lang.org/issues/19877 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-08T23:08:32Z master b635a66e95) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Non intuitive behavior of syntax only applied to literal value Some ruby syntax is only applied to literal value. ~~~ruby def 1.foo; end # receiver is a literal, it is Syntax Error /(?<a>)/ =~ s # receiver is regexp literal, it will assign to local variable if cond1..cond2; end # range-like syntax appears in condition, it is flipflop ~~~ If it is wrapped with parenthesis, the behavior seems not intuitive for me, and YARP parses it differently. ~~~ruby def (1).foo; end # Syntax Error def ((1;1)).foo; end # Syntax Error def ((;1)).foo; end # Syntax OK def ((1+1;1)).foo; end # Syntax OK def ((%s();1)).foo; end # Syntax Error def ((%w();1)).foo; end # Syntax OK def ("#{42}").foo; end # Syntax Error def (:"#{42}").foo; end # Syntax OK (/(?<a>)/) =~ s # assigns to a (;/(?<a>)/) =~ s # does not assigns (%s();/(?<a>)/) =~ s # assigns to a (%w();/(?<a>)/) =~ s # does not assigns (1; (2; 3; (4; /(?<a>)/))) =~ s # assigns to a (1+1; /(?<a>)/) =~ s # does not assign if ((cond1..cond2)); end # flipflop if (; cond1..cond2); end # range if (1; cond1..cond2); end # flipflop if (%s(); cond1..cond2); end # flipflop if (%w(); cond1..cond2); end # range if (1; (2; (3; 4; cond1..cond2))); end # flipflop if (1+1; cond1..cond2); end # range ~~~ I expect YARP and parse.y parses same. I expect all parenthesis-wrapped result same. I think it is simple and intuitive if parenthesis-wrapped code always behaves different from non-wrapped code because there are more complex variation like this ~~~ruby def (class A; 1; end).foo; end (break; /?<a>/) =~ s class A; /?<a>/; end =~ s ~~~ -- https://bugs.ruby-lang.org/

4 5

[ruby-core:114251] [Ruby master Bug#19779] `eval "return"` at top level raises `LocalJumpError`
by andrykonchin (Andrew Konchin) 07 Dec '23

07 Dec '23

Issue #19779 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19779: `eval "return"` at top level raises `LocalJumpError` https://bugs.ruby-lang.org/issues/19779 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Wondering whether it's intentional behaviour. It seems it's the only difference I've noticed between calling `return` with and without `eval`: ``` ruby -e 'return' ruby -e 'eval "return"' (eval):1:in `<main>': unexpected return (LocalJumpError) from -e:1:in `eval' from -e:1:in `<main>' ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:115462] [Ruby master Feature#20018] Get the error codes as Socket::EAI_XXX when getaddrinfo and getnameinfo fail
by shioimm (Misaki Shioi) 07 Dec '23

07 Dec '23

Issue #20018 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #20018: Get the error codes as Socket::EAI_XXX when getaddrinfo and getnameinfo fail https://bugs.ruby-lang.org/issues/20018 * Author: shioimm (Misaki Shioi) * Status: Open * Priority: Normal ---------------------------------------- Feature for implementing Happy Eyeballs version 2 (RFC 8305) in `Socket.tcp`. ### Probrem I would like to implement Happy Eyeballs version 2 (RFC 8305) in `Socket.tcp`. In HEv2, `EAI_ADDRFAMILY` and `EAI_AGAIN` should be ignored when `getaddrinfoo` returns them in hostname resolution. However, there is currently no way to ask `SocketError` for errors returned by `getaddrinfo` ### Proposal I opened a PR to get errors when `getaddrinfo` and `getnameinfo` returns them. https://github.com/ruby/ruby/pull/9018 Todo this, - I added `Socket::ResolutionError` as a subclass of `SocketError` - I added an attribute of `Socket::ResolutionError` to get error code via `#error_code - I replaced `SocketError` (`rb_eSocket`) with `Socket::ResolutionError (`rb_eResolutionError`) in `rsock_raise_socket_error` because this function is only called when `getaddrinfo` and `getnameinfo` fail - I renamed `rsock_raise_socket_error` to `rock_raise_resolution_error` for the same reason In addition, `Socket::ResolutionError` is a subclass of `SocketError`, so it does not affect `rescue SocketError` in source codes. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115634] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 07 Dec '23

07 Dec '23

Issue #18368 has been updated by zverok (Victor Shepelev). @naruse Is there a chance for this change to be included in 3.3? ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-105569 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115632] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by tbsprs (Tobias Preuss) 07 Dec '23

07 Dec '23

Issue #11322 has been updated by tbsprs (Tobias Preuss). Thanks for following up. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105566 * Author: tbsprs (Tobias Preuss) * Status: Closed * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115629] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter
by k0kubun (Takashi Kokubun) 07 Dec '23

07 Dec '23

Issue #18980 has been updated by k0kubun (Takashi Kokubun). Description updated Status changed from Open to Assigned Assignee set to k0kubun (Takashi Kokubun) Target version set to 3.4 In today's Developers Meeting, @matz accepted to warn `it` in Ruby 3.3 and add `it` in Ruby 3.4. Quote from the meeting notes: > * matz: accept `it` on Ruby 3.4. > * ruby 3.3 will warn and ruby 3.4 will use the new semantics I also copied the discussed specification to the ticket description. In Ruby 3.3, `it` should be warned only when `it` will behave like `_1` in Ruby 3.4. ---------------------------------------- Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter https://bugs.ruby-lang.org/issues/18980#change-105563 * Author: k0kubun (Takashi Kokubun) * Status: Assigned * Priority: Normal * Assignee: k0kubun (Takashi Kokubun) * Target version: 3.4 ---------------------------------------- ## Problem Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`. ```rb [1, 2, 3].each { puts _1 } ``` I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB. <details> <summary>Why I don't use <code>_1</code></summary> I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common. If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`. </details> ## Proposal * Ruby 3.3: Warn `it` method calls without a receiver, arguments, or a block. * Ruby 3.4: Introduce `it` as follows. ### Specification ```rb [1, 2, 3].each { puts it } ``` `it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments. <details> <summary>Full specification</summary> ```ruby # Ruby 3.4 def foo it #=> method call _1 #=> method call 1.times do p it #=> 0 it = "foo" p it #=> "foo" p _1 #=> 0 _1 = "foo" # Syntax Error p _1 #=> N/A p foo #=> method call foo = 1 p foo #=> local var it "foo" do # method call (rspec) end end 1.times do || p _1 # Syntax Error it # method call end 1.times do ["Foo"].any? {|| it } # method call end yield_1_and_2 do # yield 1, 2 p _1 #=> 1 p it #=> 1 end yield_ary do # yield [1, 2] p _1 #=> [1, 2] p it #=> [1, 2] end 1.times do p [_1, it] # Syntax Error p [_2, it] # Syntax Error end end ``` </details> ## Past discussions * [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`. * 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-… * 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8… * 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118) * [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`. * 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1c… * [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged. * [Feature #18980] Re-reconsider numbered parameters: (this ticket) * 2022/09/08: [Ruby Committers vs the World](https://youtu.be/ajm3lr6Y9yE?si=yyWGiZHoUWqZiTaS&t=2920) ### Compatibility `it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`? The following cases have been discussed: * `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)) * `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined. With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them. Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years. ### Confusion We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points: * RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end` * `it` could be a local variable or `_1`, depending on the situation My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument. I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115628] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by hsbt (Hiroshi SHIBATA) 07 Dec '23

07 Dec '23

Issue #11322 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed I merged https://github.com/ruby/open-uri/pull/18. Thanks all. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105562 * Author: tbsprs (Tobias Preuss) * Status: Closed * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115627] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by akr (Akira Tanaka) 07 Dec '23

07 Dec '23

Issue #11322 has been updated by akr (Akira Tanaka). I agree with `max_redirects` option. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105561 * Author: tbsprs (Tobias Preuss) * Status: Assigned * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0