Hacker News Reader

Comment by bzbarsky | Hacker News Reader

The spec on this is at http://url.spec.whatwg.org/#dom-url-host and says:

    If url is null, return the empty string.

    If port is the empty string, return host, serialized.

    Return host, serialized, ":", and port concatenated.

So what is port in this case? That's defined at http://url.spec.whatwg.org/#port-state and the key step is:

  2.  If buffer is equal to url's scheme's default port,
      set buffer to the empty string.

So IE is wrong and the MDN documentation is misleading. I've fixed the latter; can't do much about IE. ;)

View on HN

This is exactly the explanation I needed, thank you.

I wonder what the rationale behind this decision was. It seems like a pretty easy way to mess up people like me :D. Any ideas?

Probably some combination of "this is what most browsers do" and wanting to have "http://foo.com:80" and "http://foo.com" have the same underlying representation.

I don't think he's arguing that "http://example.com:80" and "http://example.com" should have different representations: I (and I think he) agrees they should, but that the representation should be "example.com:80", in both cases. I'm not so sure about host, but having port sometimes be "" seems like it could catch people off guard. For host, you now need to watch out for the cases where the port is/isn't present. For port, when it's "".

To me, it's like the type of the variable. The variable "port" should contain the port, not (port|"").

Ah, fair. The fact that port ends up as "" if it's default is almost certainly a "this is what most browsers do" kind of thing.

I think they just wanted to consistently handle the port, rather than exclude it when it is the default. I can understand wanting to be consistent, but their implementation even goes against the W3 specs: http://www.w3.org/TR/url/#url-decomposition-idl-attributes

But isn't Chrome still doing the wrong thing when given https://foo.com:443?

No, because 443 is the default port for https, so it is reset to empty string.

I don't see anywhere in the spec where is says that's okay to do.

> 2. If buffer is equal to url's scheme's default port, set buffer to the empty string.

2. If buffer is equal to url's scheme's default port, set buffer to the empty string.

Second link in bzbarsky's post?

General note to OP and others relying on MDN - if you do spot errors, please remember that it is a Wiki. You can just hit the "edit" button and fix it yourself .. and you'll be helping a ton of others along the way.

That sounds, bizarrely, like the correct behavior when the default port is used would be to have a trailing ":", i.e. "clef.io:"

I'm not so sure... I assume you're referring to this line:

    Return host, serialized, ":", and port concatenated.

...except if the port is an empty string, the process will terminate one step sooner:

    If port is the empty string, return host, serialized.

So there would be no trailing colon, in that case.

Oh, I see now. You are correct.

Reply on news.ycombinator.com