This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
IE, WebKit/Blink both sets the port to 0 when host is set to an invalid port. var a = document.createElement('a'); a.href = 'http://abc.de:8080/path/name?search#hash' a.host = 'changed:invalid'; assert(a.href === 'http://changed:0/path/name?search#hash'); Firefox keeps the old port assert(a.href === 'http://changed:8080/path/name?search#hash');
Gecko's behavior seems most consistent with how we treat invalid values elsewhere. E.g. "http://test:test/" won't even turn into a URL.
I agree that setting the port to 0 in this case is strange. Here is my unified proposal: 1. href setter is special that it will allow invalid values to be directly forwarded as input (except for URL where invalid urls throw). 2. All other setters, if the url becomes invalid due to the change we either throw or ignore the change. IE throws in a lot of these cases which makes me believe we could get away with even throwing for the non URL interfaces.
In the past we usually decided to not throw if browsers differ. Although the .protocol thing is annoying.
Presto keeps the old hostname and port: assert(a.href === 'http://abc.de:8080/path/name?search#hash'); I would be fine with either Presto or Gecko. The spec currently matches Gecko, right? (WebKit/Blink set port to 0 for a.port = 'invalid' also, FWIW.)
Yes, per the specification the URL's host will have been changed, but the URL's port will not have been changed. This matches Gecko and falls out of the way the parser is defined (although one could imagine other ways of defining it by using a fresh URL object for instance and replacing components).