Misc #15893: open-uri: URI.open status

• Status: Closed
• Assignee: akr (Akira Tanaka)

[zverok (Victor Shepelev)]

On the one hand, Ruby 2.5's NEWS stated:

URI.open method defined as an alias to open-uri's Kernel.open. open-uri's Kernel.open will be deprecated in future.

I believe there were good reasons for that decision.

On the other hand,

• no movements in this direction were done since 2.5
• URI.open is excluded from open-uri's docs, and the main library's documentation doesn't mention this option as preferred or even existing.

I'd like to know what the real status of this library and its migration to (safer) URI.open?
Should a patch be provided to change the library's docs accordingly?
Maybe even change the code (still leaving Kernel.open option, but just as an alias, moving the implementation away from that method)?

[jeremyevans0 (Jeremy Evans)]

• File deprecate-open-uri-kernel-open.patch deprecate-open-uri-kernel-open.patch added
• Status changed from Open to Assigned
• Assignee set to akr (Akira Tanaka)

While the conversion from open or Kernel.open to URI.open is simple, this is likely to break a lot of existing Ruby code. However, I can see the security advantages of deprecating this, as having open implicitly open URIs is a security footgun. For that reason, I am in favor of the deprecation and eventual removal.

akr is the maintainer of open-uri, so I'm assigning this to him. In case he decides to deprecate this, attached is a patch for the deprecation. It makes Kernel.open call URI.open in cases where URI.open would handle it, warning in that case. To avoid warning when calling Kernel.open with a Pathname instance, it does not delegate to URI.open if the object responds to to_path.

[akr (Akira Tanaka)]

• Status changed from Assigned to Closed

Applied in changeset git|05aac90a1bcfeb180f5e78ea8b00a4d1b04d5eed.

---

Warn open-uri's "open" method at Kernel.

Use URI.open instead.

Thanks for the patch by jeremyevans0 (Jeremy Evans) [Misc #15893].

[cabo (Carsten Bormann)]

So what is code that needs to be portable to older Rubies supposed to call now? URI.open only works since 2.5. We need to support 2.3 and 2.4 as well.

OpenURI.open_uri ?

[akr (Akira Tanaka)]

cabo (Carsten Bormann) wrote in #note-3:

So what is code that needs to be portable to older Rubies supposed to call now? URI.open only works since 2.5. We need to support 2.3 and 2.4 as well.

OpenURI.open_uri ?

You can use URI#open.

% ruby-2.3.0 -ropen-uri -e 'URI("http://www.ruby-lang.org").open {|f| p f.read[1..20] }'
"!DOCTYPE html>\n<html"
% ruby-2.4.0 -ropen-uri -e 'URI("http://www.ruby-lang.org").open {|f| p f.read[1..20] }'
"!DOCTYPE html>\n<html"
% ruby-2.5.0 -ropen-uri -e 'URI("http://www.ruby-lang.org").open {|f| p f.read[1..20] }'
"!DOCTYPE html>\n<html"
% ruby-2.6.0 -ropen-uri -e 'URI("http://www.ruby-lang.org").open {|f| p f.read[1..20] }'
"!DOCTYPE html>\n<html"
% ruby-2.7.0 -ropen-uri -e 'URI("http://www.ruby-lang.org").open {|f| p f.read[1..20] }'
"!DOCTYPE html>\n<html"

Note that Ruby 2.3 is already EOL and Ruby 2.4 will be EOL soon (2020-03-31).
https://www.ruby-lang.org/en/downloads/branches/

[cabo (Carsten Bormann)]

Thank you. So I gather

URI.open(url, **options)

becomes

URI(url).open(**options)

(Re the deprecation of old Ruby versions: users of gems often want to use them with whatever is on their OS, and that currently means we really have to go back to 2.3. We sure don't like that situation.)

[byroot (Jean Boussier)]

• Related to Feature #19630: [RFC] Deprecate `Kernel#open("|command-here")` due to frequent security issues added