WordPress.org

Make WordPress Core

Changes between Version 6 and Version 7 of Ticket #35248, comment 9


Ignore:
Timestamp:
05/23/2017 04:47:34 PM (3 years ago)
Author:
qdinar
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35248, comment 9

    v6 v7  
    2222then the author (Jonathan de Boyne Pollard) cites rfc 2396 and regrets about it changed according to the established human behaviour ie de facto standarts, says that better would be if browsers obeyed rfc 1738, and recommends to all people to use only fqdn, in all places, as it was commanded by rfc 1738.
    2323
    24 -- but what would happen if people obeyed rfc 1738? urls like "http://example.com/test.html" and "http://localhost/test.html" all had to be rewritten as "http://example.com./test.html" and "http://localhost./test.html". browser would have to either mark hosts without dots as error, or redirect on clicking them to full/absolute form of them. all people who configured local top-level domains like "localhost" would have to configure their servers to accept only requests for domains like "localhost." , or accept and redirect [all urls inside] "localhost" to [corresponding urls in] "localhost.". text like "localhost" would stay useful only when typing it in browser address bar, but that would be only very useless usage, and the relative domain feature is not neeeded for that, because browsers search for domains on typing. usage of them in html source would become useless because it would lead to that such links would not work, or clicking all links with "localhost" would move user to "localhost." and it would be just extra redirect on every click (on such links). so, rfc 1738 would make the planned "relative domain" feature entirely useless. if some company used that feature, and used their relative domains in their local sites, and their urls with relative domains were not redirected to absolute form by browsers, so their sites worked normally, if they also obeyed rfc 1736, they would configure their servers to accept only fqdn, and they would have to either rewrite all their such urls with fqdn, or work with extra redirect on every click on such urls. if that companies liked having short domain like "team101" instead of "team101.microsoft.com." in their address bars and html sources, they would have to start to use their custom internal top-level domains like "team101." ie like "localhost." instead of subdomains like "team101.microsoft.com." (which could be used as just "team101" before they decided to obey rfc 1738).
     24-- but what would happen if people obeyed rfc 1738? urls like "http://example.com/test.html" and "http://localhost/test.html" all had to be rewritten as "http://example.com./test.html" and "http://localhost./test.html". browser would have to either mark hosts without dots as error, or redirect on clicking them to full/absolute form of them. all people who configured local top-level domains like "localhost" would have to configure their servers to accept only requests for domains like "localhost." , or accept and redirect [all urls inside] "localhost" to [corresponding urls in] "localhost.". text like "localhost" would stay useful only when typing it in browser address bar, but that would be only very useless usage, and the relative domain feature is not needed for that, because browsers search for domains on typing. usage of them in html source would become useless because it would lead to that such links would not work, or clicking all links with "localhost" would move user to "localhost." and it would be just extra redirect on every click (on such links). so, rfc 1738 would make the planned "relative domain" feature entirely useless. if some company used that feature, and used their relative domains in their local sites, and their urls with relative domains were not redirected to absolute form by browsers, so their sites worked normally, if they also obeyed rfc 1736, they would configure their servers to accept only fqdn, and they would have to either rewrite all their such urls with fqdn, or work with extra redirect on every click on such urls. if that companies liked having short domain like "team101" instead of "team101.microsoft.com." in their address bars and html sources, they would have to start to use their custom internal top-level domains like "team101." ie like "localhost." instead of subdomains like "team101.microsoft.com." (which could be used as just "team101" before they decided to obey rfc 1738).
    2525
    2626---
     
    5757>Unfortunately, the people implementing web browser clients appeared not to understand what this meant. When you access a web site, the value most web browsers put in the "Host:" field is what the user typed, not what the computer actually ended up using, after applying the DNS user's searchlist to constuct a fully-qualified name from the partial name. For example, here are three different ways the user may refer to the host "www.example.com." ... When sending the "Host:" parameter to the web server, the web browser client puts in what the user typed ("www.example.com.", "www.example.com", or "www") instead of what the client ended up actually looking up in DNS ("www.example.com." in all three cases). ...
    5858
    59 -- this is not very true(correct), because rfc 1738 was very strict, and it disallowed relative domains in all urls, even if it is in browser's address bar, and url itself is the [recommended] way of making any references to sites, even if people write it on paper, so it was not not allowed to users to refer to that site in that 3 ways, by rfc 1738, if that users were going to think by it that they used URL!
     59-- this is not very true(correct), because rfc 1738 was very strict in this regard, and it disallowed relative domains in all urls, even if it is in browser's address bar, and url itself is the [recommended] way of making any references to sites, even if people write it on paper, so it was not allowed to users to refer to that site in that 3 ways, by rfc 1738, if that users were going to think by it that they used URL!
    6060
    6161and seems the author of this text (Stuart Cheshire) did not know about rfc 2396, so this text is outdated.