This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Both WebKit/Blink and Gecko strip leading slashes when setting hostname. IE throws. a = document.createElement('a'); a.href = 'http://abc.de:8080/path/name?search#hash' a.hostname = '///xyz'; assert(a.href === 'http://xyz:8080/path/name?search#hash') I'm also fine throwing in cases like these but we should specify what the intended behavior is.
So you parse using http://url.spec.whatwg.org/#hostname-state as override state. It will lead to "host" being the empty sequence which will lead to the host parser returning failure which means the parse operation will return failure. Which means host remains unchanged.
Note that ignoring invalid values is consistent with eg: a.hostname = "a a"
In cases like these. Are we trying to spec what browsers do or what we want them to do? If we are making changes I think I would prefer us to follow IE in these cases and throw instead of silently ignoring.
I'm not sure that specifying what IE does make sense. E.g. if I try a = document.createElement("a") a.href = "http://example" a.hostname = "a:a" IE does not throw. But if I then read a.hostname it throws. Do we really want to define that? For most other cases we silently ignore errors. Starting to throw could cause more breakage in sites. Apple is typically extremely hesitant to switch from non-throwing to throwing as well.
Ignore was fine in bug 23474 too.