Assigning a hostname property of URL object differs from node.js
Reported by
styfle...@gmail.com,
Mar 6 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Steps to reproduce the problem: Run the code from "url.hostname" section here: https://nodejs.org/api/url.html#url_url_hostname var myURL = new URL('https://example.org:81/foo'); console.log('original: ', myURL.hostname); myURL.hostname = 'example.com:82'; console.log('hostname: ', myURL.hostname); console.log('href: ', myURL.href); What is the expected behavior? The new hostname should print "example.com". The new href should print "https://example.com:81/foo". What went wrong? The new hostname is now an empty string "". The new href is now "https://example.com:82:81/foo". Did this work before? N/A Chrome version: 64.0.3282.186 Channel: stable OS Version: 10.0 Flash Version: Compare this code to Node.js which works as expected.
,
Mar 7 2018
,
Mar 7 2018
styfle123@ Thanks for the issue. Able to reproduce the issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 67.0.3362.0 and Stable 65.0.3325.146 by following the steps given above. On execting the code given above in Devtools -> Console, can observe that the Hostname is empty and new href is https://example.com:82:81/foo. Attached is the screen shot for reference. This is a Non-Regression issue as this behavior is observed from M60 Chrome builds. Hence marking this as Untriaged for further updates from Dev. Thanks..
,
Mar 9 2018
,
Mar 10 2018
AFAICT as per the spec it should be possible to specify hostname:port in URL#hostname setter. The hostname should be set and the port should be ignored. https://url.spec.whatwg.org/#hostname-state 4. Set url’s host to host, buffer to the empty string, and state to port state. 5. If state override is given and state override is hostname state, then return. Apparently the bug stems from the confusion with URL#hostname getter which doesn't return the port unlike URL#host getter. The behavior is observable since 32.0.1667.0 where DOM URL interface was first implemented in Chrome.
,
Mar 12 2018
Checked the issue again on the latest Canary 67.0.3368.0 and Stable 65.0.3325.146 and the observed the same behavior as mentioned in comment #3 in M-60 chrome builds. Hence marking this as Untriaged for further updates from Dev. Thanks..
,
Mar 12 2018
This is tested in https://wpt.fyi/url/url-setters.html, specifically the "Stuff after a : delimiter is ignored" tests. It's implemented in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/url/DOMURLUtils.cpp?q=DOMURLUtils::setHostname in a way that bears little resemblance to the standard. mkwst: is it okay for URL setters to result in invalid URLs?
,
Jun 1 2018
Possibly related, once you try to set a hostname with a port, the `.search` setter API is broken.
```
const url = new window.URL('https://.');
url.hostname = 'womp.womp'
url.search = 'one'
console.log(url.href) // "https://womp.womp/?one" 👍
url.hostname = 'womp.womp:3000'
url.search = 'two'
console.log(url.href) // "https://womp.womp:3000/?one" 👎
```
The expected output for the last line is "https://womp.womp/?two" which is what you see in other browsers.
,
Jun 1 2018
> url.search is also getting emptied...
> url = new URL('https://a.com/');
> url.hostname = 'womp.com'
> url.search = 'one'
> console.log(url.href) // "https://womp.womp/?one" 👍
> url.hostname = 'womp.com:3000'
> url.search = 'two'
> console.log(url.href) // "https://womp.womp:3000/?one" 👎
> console.log(url.search, url.href)
https://womp.com/?one
https://womp.com:3000/?one
https://womp.com:3000/?one
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tkent@chromium.org
, Mar 7 2018Labels: Hotlist-Interop