Agreed that we should at least have an example for this. Not sure what the right behaviour should be though. Removing the brackets leads to an ambiguity as to what should happen when you set the attribute to an IPv6 address (the UA has to recognise it as such and add brackets).

Anyway, I'm going to punt on this pending Adam's URL spec.

This is covered by this test suite:
http://trac.webkit.org/export/LATEST/trunk/LayoutTests/fast/url/segments.html

mass-moved component to LC1

Why would the brackets be removed? How can you then distinguish it from other host names?

(In reply to comment #4)
> Why would the brackets be removed? How can you then distinguish it from other
> host names?

If it has a colon, it is IPv6 address.
Brackets seem to be required to distinguish from the separator of port, but it won't appear here.

But then scripts that combine the components back together need to first check if the hostname contains a colon so they can add the brackets back. That does not seem ideal.

(In reply to comment #6)
> But then scripts that combine the components back together need to first check
> if the hostname contains a colon so they can add the brackets back. That does
> not seem ideal.

If you want to combine the components, you should use window.location.host,
or just use windows.location.
Such usecase is not intended for this property.
See also https://developer.mozilla.org/en-US/docs/DOM/window.location?redirectlocale=en-US&redirectslug=window.location

I think, it doesn't have brackets because hostname means DNS name.

Well, MDN is nice, but it's not a reference for the standard. It just describes what Gecko does.

As Hixie indicates in comment 1 it also complicates the algorithm for setting because now you have to distinguish IPv6 addresses from everything else in two ways. I do not think what Gecko is doing here makes sense.

Is here thinking ideal behavior of Location object,
or reverse engineering existed implementations/web pages?

The majority of existed web world is IE and Gecko,
and they do the same behavior for setting correct IPv6 address.
So if here is the latter, thinking the behavior makes sense or not is nonsense.


Moreover IPv6 within brackets is URI specific syntax.
In RFC2396 (and RFC 2732) there is "hostname" but its definition is
      hostport      = host [ ":" port ]
      host          = hostname | IPv4address | IPv6reference
      ipv6reference = "[" IPv6address "]"
      hostname      = *( domainlabel "." ) toplabel [ "." ]

RFC 3986 doesn't have "hostname":
      host        = IP-literal / IPv4address / reg-name
      IP-literal = "[" ( IPv6address / IPvFuture  ) "]"

Therefore thinking window.location.hostname is a host defined in RFC3986 doesn't have reason.

I guess we need some tests here for setting and getting hostname. E.g. Gecko does support brackets as input. It seems kinda cumbersome to design a completely separate parser from the normal host parser, but the point that we might need to do this for compatibility is fair.

Okay, so fixing this would be rather easy. When serializing we'd special case IPv6 and when parsing we'd first check for a colon and then prepend input with [ and append ] to it.

However, given that we need to do that special casing it seems what Safari and Chrome are doing is much more sensible.

Gecko was able to change its parser without a hiccup. Seems it still serializes wrong though. Filed a bug on that.

Marking this WONTFIX. Feel free to reopen if this cannot be done for some reason.