Resource deletion operations fail because of double slash in REST API URL

[gsx]

There is a bug in MsRest::HTTPOperationRequest which causes Azure::ARM::Resources::Resources#delete_by_id (and presumably some other methods) to fail with a somewhat obscure stack trace.

Faraday::ConnectionFailed: Failed to open TCP connection to subscriptions:443 (getaddrinfo: No address associated with hostname)
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb:882:in `rescue in block in connect'
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb:879:in `block in connect'
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout'
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/timeout.rb:101:in `timeout'
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb:878:in `connect'
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb:863:in `do_start'
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb:852:in `start'
	from /home/gabor/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb:1398:in `request'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/faraday-0.10.1/lib/faraday/adapter/net_http.rb:83:in `perform_request'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/faraday-0.10.1/lib/faraday/adapter/net_http.rb:41:in `block in call'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/faraday-0.10.1/lib/faraday/adapter/net_http.rb:88:in `with_net_http_connection'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/faraday-0.10.1/lib/faraday/adapter/net_http.rb:33:in `call'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/faraday-cookie_jar-0.0.6/lib/faraday/cookie_jar.rb:22:in `call'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/ms_rest-0.6.2/lib/ms_rest/retry_policy_middleware.rb:29:in `call'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/faraday-0.10.1/lib/faraday/rack_builder.rb:139:in `build_response'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/faraday-0.10.1/lib/faraday/connection.rb:377:in `run_request'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/ms_rest-0.6.2/lib/ms_rest/http_operation_request.rb:80:in `block in run_promise'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/safe_task_executor.rb:24:in `block in execute'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `block in synchronize'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/safe_task_executor.rb:19:in `execute'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/promise.rb:531:in `block in realize'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/ruby_thread_pool_executor.rb:348:in `run_task'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/ruby_thread_pool_executor.rb:337:in `block (3 levels) in create_worker'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `loop'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `block (2 levels) in create_worker'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `catch'
	from /home/gabor/.rvm/gems/ruby-2.3.0@part2-project/gems/concurrent-ruby-1.0.4/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `block in create_worker'

To reproduce, create a new resource group named test, within it create a new network interface called test, and then try to use the script below to destroy it. The result should be similar to the stack trace above.

require 'azure_mgmt_resources'

client_id = 'REDACTED'
client_secret = 'REDACTED'
tenant_id = 'REDACTED'
subscription_id = 'REDACTED'

provider = MsRestAzure::ApplicationTokenProvider.new(tenant_id, client_id, client_secret)
credentials = MsRest::TokenCredentials.new(provider)

resource_client = Azure::ARM::Resources::ResourceManagementClient.new(credentials)
resource_client.subscription_id = subscription_id

api_version = '2016-10-01'
resource_client.resources.delete_by_id "/subscriptions/#{subscription_id}/resourceGroups/test/providers/Microsoft.Network/networkInterfaces/test", api_version

The bug is caused by handing a relative path starting with two slashes to URI.parse, which will then interpret the first segment as a host name. MsRest::HTTPOperationRequest#build_path tries to remove redundant slashes using a regexp, but the regexp fails to take into account the case where the double slash occurs at the very beginning of the path, as is the case with paths generated during a delete_by_id operation.

A 3 character monkey patch will follow in the form of a pull request shortly.

[vishrutshah]

@gsx Thank you very much for taking time to contribute towards fix.