WHATWG URL API: base ignored if relative path starts with a double slash

[scottinet]

• Version: 12.13.1
• Platform: all
• Subsystem: url

Instantiating a new WHATWG URL with a base option, and a relative URL starting with a double slash ends up with the base option being ignored.

How to reproduce

const foo = new URL('//foo/bar', 'http://fake');

Expected result

URL {
  href: 'http://fake//foo/bar',
  origin: 'http://fake',
  protocol: 'http:',
  username: '',
  password: '',
  host: 'fake',
  hostname: 'fake',
  port: '',
  pathname: '//foo/bar',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}

Actual result

URL {
  href: 'http://foo/bar',
  origin: 'http://foo',
  protocol: 'http:',
  username: '',
  password: '',
  host: 'foo',
  hostname: 'foo',
  port: '',
  pathname: '/bar',
  search: '',
  searchParams: URLSearchParams {},
  hash: ''
}

[jasnell]

Per the URL standard, this appears to be working as expected. That is, the actual result above is correct and you should see similar/identical results both in Chrome and Firefox.

[scottinet]

I see, the protocol can be relative, and the documentation does state that the base is used if the URL is not absolute. Then again, this is a bit of a edge case: I cannot have relative URLs starting with a double-slash with the WHATWG URL API (as dubious as that might be), even though this makes for a perfectly valid relative URL.

[jasnell]

It may be worth opening an issue in the url standard repo

[scottinet]

Yeah, sorry for that issue, I didn't know about the relative protocol thing. 😑
I was trying to reproduce the same behavior as with the legacy URL api with WHATWG but concerning this very particular and not very interesting case, we'll just make our HTTP router stricter.

Thanks for looking into this. 👍