SoylentNews is people
SoylentNews
Google Achieves Its Goal of Erasing the WWW Subdomain From Chrome
With the release of Chrome 79, Google completes its goal of erasing www from the browser by no longer allowing Chrome users to automatically show the www trivial subdomain in the address bar.
When Chrome 76 was released, Google decided to no longer show the www "trivial subdomain" in the address bar when visiting a web site. This means, that if you are visiting www.bleepingcomputer.com, Chrome would only show bleepingcomputer.com in the address bar...
[...] According to a Google engineer, www is considered a trivial subdomain because "this isn't information that most users need to concern themselves with in most cases".
Many users, though, felt that this was a security issue, could be confusing for users, and is technically incorrect because www.domain.com is not always the same host as domain.com.
So is this a distinction without a difference or a real issue?
(Score: 0) by Anonymous Coward on Sunday December 15 2019, @06:15PM (14 children)
Another test, this time using the wonderful Toronto jazz station:
Typing "jazz.fm" into Firefox displays (after a moment) as "https://jazz.fm" and copy-paste here gives "https://jazz.fm/" -- so FF is not displaying the final "/"
Typing "jazz.fm" into Chrome displays as "jazz.fm" Selecting and left-arrow then displays "https://jazz.fm" and copy-paste does the same as FF, "https://jazz.fm/"
(Score: 3, Insightful) by barbara hudson on Sunday December 15 2019, @06:53PM (11 children)
That FF doesn't then display the trailing slash is an error in terms of following the standard, because it's supposed to show where you are currently, not where you started from.
When you write a web server, you will add the trailing slash so that any other links generated by the page work out. Otherwise, instead of https:/soylentnews.org/comments.pl, you'd get https:/soylentnews.orgcomments.pl. which just doesn't resolve to anything rational.
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 2, Informative) by Anonymous Coward on Sunday December 15 2019, @11:27PM (10 children)
Wrong on both parts. According to Section 5 of RFC 1738, the BNF for a url is:
For HTTP schemes, they are defined as:
You'll notice that the slash after the hostport is required only if you include a path or a query, or, as 3.3 puts it, "If neither <path> nor <searchpart> is present, the "/" may also be omitted." Which makes since because scheme normalization states that empty paths should be normalized to "/". They are literally references to the same location, and no redirects are required. In fact, a redirect from one to the other or serving different content is a violation of the RFCs for most Internet protocols, including HTTP.
In addition, hosts are defined in 3.1 as:
And none of the referenced RFCs describe the SERVICE.WHATEVER syntax you describe.
(Score: 2) by barbara hudson on Monday December 16 2019, @12:51AM (7 children)
Read the man pages. If you're going to actually implement a server, they're the authoritative source. Not the RFCs. They don't do anything for giving actual implementation details. Where's SO_KEEPALIVE and SO_LINGER in your RFC? Nowhere. They are far from complete when it comes to actually implementing a server. Where's the description of how to open a socket? How to close it properly? Nowhere.
Anyone can quote an RFC. Implementation in C is hard. And the C source is authoritative. Not an RFC that doesn't include any implementation details.
Call me back when you've implemented a server in c. (not any chickenshit scripting language).
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 1, Touché) by Anonymous Coward on Monday December 16 2019, @04:35AM (5 children)
Since I've already passed your last hurdle. I'll address your point. The RFCs are the authoritative source, short of market capture. The whole reason for the RFC is so that the networked systems use the same rules and speak the same language. If you are trying to write a server and your response does not follow the RFC, then the client won't properly understand you. Likewise, if you have a client send a non-complaint request, the server won't follow it either. Best case scenario is that they guess correctly (e.g. see various handling of "ICY 200 OK" responses), worst case you get garbage or a cryptic socket error when they disconnect on you.
And, by the way, implementation-specific socket options have nothing to do with that common language. You can implement a server, even an HTTP one, just fine without either SO_KEEPALIVE or SO_LINGER. You can't do it without following the protocols. The way you imagine it is that recipes should include instructions on what buttons to push to turn on your oven. But, I'll check the man page [debian.org] anyway. OH what is that? The synopsis says the slash at the start of the absolute path is optional. And no mention of your SERVICE.DOMAIN.TLD domain name setup either. And some of that BNF looks familiar. It is almost like they copied it from the RFC.
(Score: 2) by barbara hudson on Wednesday December 18 2019, @02:04AM (4 children)
There is NO requirement that everyone on the net "speak the same language." Or have you forgotten AlterNIC? Great idea that temporarily broke the monopoly on domain names. We really should bring it back.
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 0) by Anonymous Coward on Thursday December 19 2019, @08:27AM (3 children)
AlterNIC was speaking the same language. They were an alternate root, but they still used the same DNS protocol as the other roots, including the Network Information Center. It literally wouldn't have worked off the shelf and been an even larger failure if it hadn't done so.
Fact of the matter is that if the server/clients/peers don't speak the same language in the form of common standards, then they cannot communicate with each other reliably. For example, if you send, "/favicon.ico\r\n" to a web server or "GET /images/logo.png HTTP/1.0\r\n\r\n" to a gopher server, they won't understand you and give you garbage, if anything. And, as I mentioned, if not for market capture making you the de facto standard, the RFCs are as close as you'll get to that common baseline for most web related things that don't have standards elsewhere.
Besides, your just salty that your precious man pages proved you wrong because you didn't bother to look it up.
(Score: 2) by barbara hudson on Thursday December 19 2019, @06:33PM (2 children)
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 0) by Anonymous Coward on Thursday December 19 2019, @08:14PM (1 child)
I'm not sure what you are saying. Are you claiming that HTTP is the only protocol that runs over TCP/IP (which is actually two different protocols that can be used independently) or UDP? If so, I've got news for you [wikipedia.org].
If you are instead saying that the transport network layer doesn't really care what is carried in it in the designated place on a higher layer protocol as long as it conforms to the requirements of its own layer standard. Then yes, that is what they are designed to do, but that doesn't mean that you can arbitrarily provide all data and not meet the requirements at your level. And that doesn't mean that servers working at the application layer will magically read your mind when you don't follow the common standards for that particular protocol.
(Score: 2) by barbara hudson on Thursday December 19 2019, @08:42PM
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 1) by Mike on Monday December 16 2019, @06:01PM
I was trying to stay out of this thread, but I'm appalled enough at the following statement that I just can't help myself.
The RFC's are the specification for the protocol. Your server is the implementation. The MAN page for the server is a description of how that server works. The specification (i.e. RFC's) is authoritative. In general, when the implementation doesn't match the specification, the implementation is at fault. (occasionally, an implementation will find a problem with a specification. Then the RFC's needs to be updated/changed. Because the specification is authoritative!)
FWIW, I haven't written any web servers. But I have created multiple implementations of multiple protocols as defined by multiple RFC's. They were mostly in C or C++, so your specs are at least partially met ).
(Score: 1, Redundant) by Mojibake Tengu on Monday December 16 2019, @01:05AM (1 child)
This syntax is incorrect. It is insufficient for hosts identified by bracketed raw ipv6 address (and port) instead of a hostname.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 0) by Anonymous Coward on Monday December 16 2019, @03:43AM
I was trying to keep it simple by not putting everything, but here is the whole thing, including the updating language of 3986:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty
URI-reference = URI / relative-ref
absolute-URI = scheme ":" hier-part [ "?" query ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = [ userinfo "@" ] host [ ":" port ]
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
host = IP-literal / IPv4address / reg-name
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3(
h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255
reg-name = *( unreserved / pct-encoded / sub-delims )
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
Still no SERVER.WHATEVER syntax and no requirement for a slash at the beginning of the path.
(Score: 3, Interesting) by hendrikboom on Monday December 16 2019, @12:13AM (1 child)
Just as most people don't know about the trailing dot in a domain name:
"jazz.fm." tells the DNS not to go looking for a jazz.fm.topoi.pooq.com, for example.
(topoi.pooq.com is my search space for local entities. I'm currently posting this from midwinter.topoi.pooq.com, which I can refer to as just midwinter)
(Score: 0) by Anonymous Coward on Monday December 16 2019, @10:42AM
I've used this to bypass some restrictions too... :)
For example: https://soylentnews.org/comments.pl?sid=35121 [soylentnews.org] is blocked by the proxy but https://soylentnews.org./comments.pl?sid=35121 [soylentnews.org.] sometimes isn't.
I think some webservers don't like that though...
Similar for email addresses etc.