Ambiguous `allowed_push_host` option

Hello everybody,

first of all thank you for being one of the pillars of the Ruby ecosystem!

I think I either observed inconsistent naming or a bug (or both?) in the configuration for custom gem servers.

This issue is related to:

• Network problems
• Installing a library
• Publishing a library
• The command line gem
• Other

Here are my current environment details:

$ gem env version
3.0.3

We are currently setting up a private gem repository (https://rubygems.pkg.github.com) for our company and I noticed an oddity regarding the allowed_push_host option.

When looking at the implementation
and the documentation of said option, it can be understood that the option expects a protocol and a registered name / hostname:

RubyGems 2.2.0 and newer support the allowed_push_host metadata value to restrict gem pushes to a single host. If you are publishing private gems you should set this value to prevent accidental pushes to rubygems.org:

 Gem::Specification.new 'my_gem', '1.0' do |s|
   # ...
   s.metadata['allowed_push_host'] = 'https://gems.my-company.example'
 end

In my opinion this might be confusing in the following ways:

1. Given the options' naming, I would expect it to receive only a registered name / hostname, not a scheme. This might be less of a problem, since URI.parse will default to https if no scheme is given.

2. It is possible to specify a full URI including port and paths, which will be silently ignored when the push target is validated. Given that users might rely on both to be enforced, this could lead to unexpected behavior.

I would like to suggest to either rename the allowed_push_host option and/or to actually enforce path and port (if given) or to include a respective hint in the documentation and a warning when more than scheme and registered name are given.

Start with lib/rubygems/gemcutter_utilities.rb and the documented allowed_push_host option, then trace how the value is interpreted during gem publishing. Clarify the intended handling of schemes, ports, and paths, and consider the issue's proposed documentation or validation outcomes as the definition of done.