4 ms·
The spec on this is at http://url.spec.whatwg.org/#dom-url-host http://url.spec.whatwg.org/#dom-url-host and says: If url is null, return the empty string.
by bzbarsky 13y ago
The spec on this is at http://url.spec.whatwg.org/#dom-url-host 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 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. ;)
- jessepollak 13y agoThis 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?
- bzbarsky 13y agoProbably some combination of "this is what most browsers do" and wanting to have "http://foo.com:80" http://foo.com:80" and "http://foo.com" http://foo.com" have the same underlying representation.
- deathanatos 13y agoI don't think he's arguing that "http://example.com:80" http://example.com:80" and "http://example.com" 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|"").
- bzbarsky 13y agoAh, 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.
- ben010783 13y agoI 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 http://www.w3.org/TR/url/#url-decomposition-idl-attributes
- jxi 13y agoWay to post a misleading title just to get views. Why does shit like this even get upvoted? Learn to read the spec.
- adestefan 13y agoBut isn't Chrome still doing the wrong thing when given https://foo.com:443 https://foo.com:443?
- kilovoltaire 13y agoNo, because 443 is the default port for https, so it is reset to empty string.
- adestefan 13y agoI don't see anywhere in the spec where is says that's okay to do.
- matchu 13y ago> 2. If buffer is equal to url's scheme's default port, set buffer to the empty string.
- interurban 13y ago2. If buffer is equal to url's scheme's default port, set buffer to the empty string.
- bronson 13y agoSecond link in bzbarsky's post?
- deleted 13y ago[deleted]
- mistercow 13y agoThat sounds, bizarrely, like the correct behavior when the default port is used would be to have a trailing ":", i.e. "clef.io:"
- md224 13y agoI'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.
- mistercow 13y agoOh, I see now. You are correct.
- aufreak3 13y agoGeneral 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.