3 ms·

> You are not aware that all browsers currently hide port numbers in the URI bar if they are 80 or 443? No, I am not, for the simple reason that that is not th

> You are not aware that all browsers currently hide port numbers in the URI bar if they are 80 or 443? No, I am not, for the simple reason that that is not the case. Browsers hide port 80 only for HTTP and port 443 only for HTTPS, because those are the well-known ports for those protocols, and the specifications of URIs and those protocols define that no port in the URI is equivalent to the well-known port, and what the well-known ports are. https://tools.ietf.org/html/rfc3986#section-3.2.3 https://tools.ietf.org/html/rfc3986#section-3.2.3 https://tools.ietf.org/html/rfc2616#section-3.2.2 https://tools.ietf.org/html/rfc2616#section-3.2.2 https://tools.ietf.org/html/rfc2818#section-2.3 https://tools.ietf.org/html/rfc2818#section-2.3 > For example, https://www.google.com/ https://www.google.com/ is actually https://www.google.com:443/ https://www.google.com:443/, but the browsers choose to hide this part. No, the browsers simply follow the relevant standards, as you can see from the links above. > Wouldn't it be better if you actually saw which port the browser connects to? No, there is no additional information in displaying the well-known port, as per the standards cited above, so it would be a completely useless waste of space. > Removing these two standard ports from the address bar is therefore exactly the same as removing other standards parts, like https:// https:// or www. What do you mean by "standards parts"? Also, could you please cite the relevant standard that specifies that http[s]://www.domain/ is equivalent to http[s]://domain/?

keymone 7y ago
> Browsers hide port 80 only for HTTP and port 443 only for HTTPS, because those are the well-known ports for those protocols how is that different from "browsers only hide www part of domain name because this is a well known historical artifact and default behavior of any sane website should be to either redirect one name to another or serve the same content on both" you're being unnecessarily and angrily pedant.
- zAy0LfpBZLC8mAC 7y ago
  > how is that different from "browsers only hide www part of domain name because this is a well known historical artifact and default behavior of any sane website should be to either redirect one name to another or serve the same content on both" That one of those is part of the relevant standards, the other is not. What your personal opinion is as to what a "sane" anything should do is just completely irrelevant for this discussion. You build reliably interoperable systems by implementing what the standard says, not by implementing what you would prefer the standard to say, because (a) if everyone just implements what they think is sane, that's guaranteed to fail at interoperating because everyone else will consider something else sane and (b) the process for building the consensus as to how to do things is the standards writing process, so if you think a standard is insane, you have to participate in the standards writing process to change the consensus on how to do things sanely, which then will be reflected in a new revision of the standard. Whether something is well known is also completely irrelevant. "Well-known port" is simply a fixed term for "ports that have been standardized as the default port for a protocol", and the only relevant fact here is that the behaviour of not displaying the port number is standardized. > you're being unnecessarily and angrily pedant. No, your kind of reasoning is precisely how a ton of interoperability problems arise, costing humanity probably billions of dollars to work around each year.
  - keymone 7y ago
    > implementing what the standard says do show me the standard that regulates how browsers ought to display identity of the site. because everything you've said is irrelevant otherwise.
    - zAy0LfpBZLC8mAC 7y ago
      I already have. There is no standard that says "how a browser ought to display identity of a site", at least none that I know of, but that doesn't mean that there is no standard that is relevant to how a browser should display URIs. There is also no standard that says "how an email client should display email addresses". Now, suppose that some email client decided to always replace the TLD in any email addresses it displayed with ".com". Is that conforming to standards because there is no standard that says "how an email client should display email addresses"? No, obviously, it's not, because the address "foo@example.com" is not guaranteed by any standard to be equivalent to "foo@example.org", say, so this transformation causes an email address to be displayed that, according to the relevant standards, is not guaranteed to be semantically equivalent (mind you: that does not mean that they can never be equivalent--there is just no guarantee that they are/there is no responsibility for the owner of those addresses to make sure that they deliver to the same mailbox). Which is in contrast to, say, displaying "foo@ExaMple.org" as "foo@example.org"--those are guaranteed to be equivalent, so substituting one for the other is acceptable. The exact same thing applies here for URIs. The URI and HTTP(S) standards specify which URIs are equivalent, and if your software displays one URI as a different URI that is not guaranteed to be equivalent, then that is in conflict with that standard.

keymone 7y ago

> Browsers hide port 80 only for HTTP and port 443 only for HTTPS, because those are the well-known ports for those protocols how is that different from "browsers only hide www part of domain name because this is a well known historical artifact and default behavior of any sane website should be to either redirect one name to another or serve the same content on both" you're being unnecessarily and angrily pedant.

zAy0LfpBZLC8mAC 7y ago
> how is that different from "browsers only hide www part of domain name because this is a well known historical artifact and default behavior of any sane website should be to either redirect one name to another or serve the same content on both" That one of those is part of the relevant standards, the other is not. What your personal opinion is as to what a "sane" anything should do is just completely irrelevant for this discussion. You build reliably interoperable systems by implementing what the standard says, not by implementing what you would prefer the standard to say, because (a) if everyone just implements what they think is sane, that's guaranteed to fail at interoperating because everyone else will consider something else sane and (b) the process for building the consensus as to how to do things is the standards writing process, so if you think a standard is insane, you have to participate in the standards writing process to change the consensus on how to do things sanely, which then will be reflected in a new revision of the standard. Whether something is well known is also completely irrelevant. "Well-known port" is simply a fixed term for "ports that have been standardized as the default port for a protocol", and the only relevant fact here is that the behaviour of not displaying the port number is standardized. > you're being unnecessarily and angrily pedant. No, your kind of reasoning is precisely how a ton of interoperability problems arise, costing humanity probably billions of dollars to work around each year.
- keymone 7y ago
  > implementing what the standard says do show me the standard that regulates how browsers ought to display identity of the site. because everything you've said is irrelevant otherwise.
  - zAy0LfpBZLC8mAC 7y ago
    I already have. There is no standard that says "how a browser ought to display identity of a site", at least none that I know of, but that doesn't mean that there is no standard that is relevant to how a browser should display URIs. There is also no standard that says "how an email client should display email addresses". Now, suppose that some email client decided to always replace the TLD in any email addresses it displayed with ".com". Is that conforming to standards because there is no standard that says "how an email client should display email addresses"? No, obviously, it's not, because the address "foo@example.com" is not guaranteed by any standard to be equivalent to "foo@example.org", say, so this transformation causes an email address to be displayed that, according to the relevant standards, is not guaranteed to be semantically equivalent (mind you: that does not mean that they can never be equivalent--there is just no guarantee that they are/there is no responsibility for the owner of those addresses to make sure that they deliver to the same mailbox). Which is in contrast to, say, displaying "foo@ExaMple.org" as "foo@example.org"--those are guaranteed to be equivalent, so substituting one for the other is acceptable. The exact same thing applies here for URIs. The URI and HTTP(S) standards specify which URIs are equivalent, and if your software displays one URI as a different URI that is not guaranteed to be equivalent, then that is in conflict with that standard.