Paths beginning with // should not be allowed when authority is present

[clayton-shopify]

According to RFC 3986 section 3.3:

If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//").

But Addressable allows such paths, which will be ambiguously interpreted as a host:

irb(main):001:0> require 'addressable/uri'
=> true

irb(main):002:0> u1 = Addressable::URI.parse('/..//example.com')
=> #<Addressable::URI:0x3ff6becfbb5c URI:/..//example.com>

irb(main):003:0> u1.normalize!
=> #<Addressable::URI:0x3ff6becfbb5c URI://example.com>

irb(main):004:0> u1.host
=> nil

irb(main):005:0> u1.path
=> "//example.com"

irb(main):006:0> u2 = Addressable::URI.parse(u1.to_s)
=> #<Addressable::URI:0x3ff6bec436b0 URI://example.com>

irb(main):007:0> u2.host
=> "example.com"

irb(main):008:0> u2.path
=> ""

This could allow URL validation logic to be bypassed.

[sporkmonger]

Interesting. Addressable uses the dotted path resolution algorithm described by RFC 3986, but apparently in this case, that results in a // prefix on the path name. I'd be inclined to raise an exception as soon as you normalized rather than normalizing paths in a way that deviates from the spec.

[clayton-shopify]

That sounds like a good approach.

Of course, normalize isn't the only way you can end up in this situation:

irb(main):001:0> require 'addressable/uri'
=> true
irb(main):002:0> u1 = Addressable::URI.new
=> #<Addressable::URI:0x3fd881114f74 URI:>
irb(main):003:0> u1.path = '//example.com'
=> "//example.com"
irb(main):004:0> u1.host
=> nil
irb(main):005:0> u2 = Addressable::URI.parse(u1.to_s)
=> #<Addressable::URI:0x3fd8810e1638 URI://example.com>
irb(main):006:0> u2.host
=> "example.com"
irb(main):007:0> u2.path
=> ""

[sporkmonger]

Yup, the validate method already addresses the multiple ways you can end up there.

[sporkmonger]

Although I did discover it wasn't correctly being called from the path= setter.