I've known people back in the 90s with user@tld domains, and they were definitely sending and receiving mail. So, even if it wasn't spec-compliant it certainly got through all the early mail relays.
I mean.. you can use emoji domains right now. They work most places for email. The part I found didn't work so well is emoji usernames on emoji domains. That has poor deliverability.
ICANN, by the way, heavily discourages such domain names, even though it can't actually prohibit them: yes, RFC 5892 explicitly prohibits emoji code points in internationalized domain names but so what? If registrars allow (and many acually do allow) registration of such names that only means that they violate some RFC and they already violate quite a lot of them. Who cares! Just pay the money and we will delegate you whatever names you want.
sure, and you can use it internally, or with your own private/internal DNS (or other name resolution system), but in practice it means that for new gTLDs it's a no-go, right?
The syntax rule for host is ambiguous because it does not completely
distinguish between an IPv4address and a reg-name. In order to
disambiguate the syntax, we apply the "first-match-wins" algorithm:
If host matches the rule for IPv4address, then it should be
considered an IPv4 address literal and not a reg-name.
But it does comply with WHATWG’s URL Standard, which declares the goal of obsoleting RFC 3986, providing something that’s actually robustly implementable, and reflecting reality.
Some things do definitely try to follow RFC 3986 still, but my feeling is that it’s mostly legacy stuff, and the URL Standard is much more important these days. Though RFCs dealing with URLs will probably still cite it (e.g. RFC 9110, HTTP Semantics, June 2022).
True, though the WHATWG algorithm still raises validation errors internally for all these cases. Meaning, while these representations are leniently accepted, they aren’t intended to be valid representations.
Usually they'll also accept octal with a leading zero (010.010.010.010 is 8.8.8.8), hexadecimal with a leading 0x, and omitted 0 octets (127.1 is 127.0.0.1). IIRC these are all adopted from BSD's sockets library, or some similar early IP implementation
Once you got that you will have a way simpler time to understand netmasks and similar and calculate IP ranges etc. it's just a 32bit integer (in ipv4; 64bit with ipv6) and the dots separate the individual bytes to give a "human friendly" representation.
IP addresses are 4 bytes, each in the range 0-255. In binary bits xyz would be equivalent to decimal x2^2+y2+z. Similarly, bytes abc would be equivalent to decimal a256^2+b256+c.
IP address p.q.r.s is decimal p256^3+q256^2+r*256+s.
You can think about it like the IP address in hex if you like: 0x01.0x01.0x01.0x01 becomes 0x01010101 which is 16,843,009. So the first 0x01 is 0x01000000 which is the familiar 16,777,216 which then gets the further "base 256 digits" added to it.
Or maybe in your terms it's 256^(0..3) where you can think of it like each dotted component is a symbol (like 0-9 in base 10) where each component is a position digit. Where the right-most element is the "256^0" ("ones") digit, and the left most element is the "256^3" ("16,777,216s") digit.
I think this post is trending because of a comment on the announcement about the new Pope, where someone pointed out the redundancy in the vatican.va domain.
Well I suppose they could. But as we've seen, there are plenty of 2nd level domains under .va, and in fact, many if not most of those, especially vatican.va, actually refer to the Holy See.
It's very common and understandable for folks to conflate the Holy See with the Vatican, but they are distinct entities with two different functions and purposes.
If we're discussing the administration/governance of the Church and the organs which make up the Roman Curia, then we're definitely looking at the Holy See. It's the Holy See, not the Vatican, which is a Permanent Observer to the U.N.
But again, if we're looking at any sort of physical presence, it's the Vatican City State. The actual territory that's an enclave and microstate is the Vatican. It's where people live, work, and worship. "The Vatican" is the entity selected for the ".va" ccTLD simply because of the way the rest of the world works. But only a few of those 2nd level domains can properly be considered more "Vatican" than "Holy See".
Most browsers treat one word not as a domain but as a search key. This was an issue when companies started getting their own TLDs. Could you just type "amazon" or "microsoft", which are TLDs, and go there without being diverted to a search engine? The answer is no. Even if you put a dot after the domain name.
DNS lookup and web browser domain lookup are not quite the same. This is the price of a unified input bar.
I never saw what was wrong with having a URL and a search box in the same bar. It was fine, and I knew that whatever I typed into the URL bar would be treated as a URL.
Fast forward a few years, and URLs I type into the bar are not treated as URLs (internal HTTP URLs get rewritten to HTTPS when a server is restarting).
Mobile Safari likes to do this to me w/ machines on my tailnet. Whether dropping "foo:8080" in the address bar takes me to the webserver or to Google is random and I swear there is no pattern
Putting a slash '/' at the end consistently gets you there, at least in Chromium-based browsers. We use this a lot at work (via DNS search suffixes, not private TLDs).
At a previous company, our intrasite was a bare custom domain, and the most reliable way to get there was to add a / at the end. This is likely browser dependent though
Ahh, I actually ran into this question, at least indirectly, about a month ago!
I was writing an email validator for my project which I'm so excited to announce soon. And my research (some stackoverflow answers) suggested that, yeah, you can have "a@b" as a valid email, as long as there's a one-letter TLD that can have MX records.
Which it seems there can be!
So my email validator is essentially just /^.{1,}@.{1,}$/ ... yay.
Last time I checked the RFC the bit before the '@' can actually be empty. And the root zone is just '.', but we generally can leave off the trailing dot in domain names. So I believe '@' on its own is a valid email address.
Many years ago I managed to get a cctld owner to point their tld MX records at my smtp server, modified postfix to allow empty usernames (even although the RFC allows them, postfix didn't), and successfully had someone send me email to '@tld', in order to win a bet. :) (And it was a 2-letter tld.)
I don't know if it is still required but hostnames used to require a minimum of two chars and the first shalt not be an integer. Given that DNS does not put a proper boundary on host/domain, that might extend to your top level ... thingie.
However, there is absolutely no technical reason that I can think of that precludes u@x. In the end DNS query -> DNS answer. Given that say, PowerDNS has LUA built in, I can make it respond with "my little pony's stable is in {random_country}" - to A record requests, which might make the requester a little queasy!
I believe that the rule has been deprecated due to better parsing.
In the mid-90s, 3M was a customer of the ISP I worked for. Unable to procure the domain name “3m.com” they settled for the alternate “mmm.com”: mildly hilarious considering their lines of business.
The best you can hope to do is reduce a small class out of possible errors. But you'll never get a test that can prevent errors like [email protected], [email protected], [email protected] etc. So is it really worth doing any checks at all?
I have a .blue email address and it's amazing how many sites still won't accept it. I keep a spare Gmail account for these.
You can do quite well at this, if you're willing to not restrict yourself to regexes and commit to some amount of hackery. One system I worked on used a simple regex (just what is described here IIRC - assert the existence of an @ sign), plus did an MX check on the domain, plus warned (not errored) if the domain was within 1 or 2 Levenshtein distance of any of a list of most common email domains (yahoo, gmail, etc). Statistically it seems like we saved people a lot of grief with this simple filtering.
The downvotes are a sign that I did not notice that my reply to the poster was not composed. I got the memo, and will take note from now on, mark my words!
.blue is 11 years old and still has issues. Same with several of the gtlds I have. I had an argument with a major backend email provider recently who refused to open an account for me as my gtld wasn't "valid." (they backed down eventually and fixed their code)
I keep a Gmail for the same reason.
I tried to add a .wiki link to a Reddit profile recently and their filters also say that domain is invalid.
which gives me the “90sdev” tag for my emails, which still go squarely into my “[email protected]” address? I don’t know what the best route is, but I’ve certainly run into bad validators that block things that otherwise work, and that’s annoying. It seems to me the best thing might be to have a user twice input their address, then have the next step/confirmation done via email.
Documented as "subadressing" in RFC 5233, and the default for both sendmail and postfix, amongst others. As such, often 'accidentially' supported by many mail providers even when undocumented. Google didn't introduce them, nor are they 'unconventional'.
Both parts are limited to 7-bit ASCII or a subset thereof. Emojis have to be in punycode. You could theoretically use UTF-7 for the local-part but nothing supports it in practice.
Trailing dot is complete record, don't add any search domains onto it. (https://en.wikipedia.org/wiki/Search_domain) It's why NS records should have trailing dot in return to prevent unexpected lookup behavior.
Technically you can put just hostname for CNAME record. Obviously, any clients that don't have that domain as search domain will fail but for internal domain, you could do it.
AFAIK calling DNS root the "." is quite recent phenomenon.
I'm fairly old guy who did work with DNS about 35 years before retirement and what I recall from the beginning when I was reading my first copy of DNS and BIND somewhat quite soon it came out -92 I think the second chapter which describes DNS root "A null (zero-length" was already there.
So a FQDN (Fully Qualified Domain Name) well known www.google.com the would be www.google.com."" where between the quotation denotes where the DNS root is shown.
However, resolvers don't recognise that syntax. Don't be fooled by
$ host www.google.com.""
www.google.com has address 216.58.209.164
www.google.com has IPv6 address 2a00:1450:4026:802::2004
from the shell as it removes those double quotes. Using single quotes around shows how that fails and you can check it easily.
$ host 'www.google.com.""'
Host www.google.com."" not found: 3(NXDOMAIN)
The way I learned to understand it the dot in DNS name is (it signifies) the DNS-tree separator, not part of the DNS name. A bit like in some languages (Pascal) use semicolon (;) a sentence separator not an end of sentence like it's in C and many it's practise adopted later.
OK, here's an excerpt from DNS and BIND by Cricket Liu & Paul Albitz, O'Reilly ISBN 0-596-10057-6, Fifth Edition 2006 book which I still have a printed copy in my shelf and shows what I'm referring above.
Chapter 2: How Does DNS Work, page 12, text after Figure 2-1 they write:
"Domain Names
Each node in the tree has a text label (without dots) that can be up to 63 characters long. A null (zero-length) label is reserved for the root. The full domain name of any node in the tree is the sequence of labels on the path from that node to the root.
Domain names are always read from the node toward the root ("up" the tree), with dots separating the names in the path.
If the root node's label actually appears in a node's domain name, the name looks as though it ends in a dot, as in "www.oreilly.com." (It actually ends with a dot—the separator—and the root's null label.) When the root node's label appears by itself, it is written as a single dot, "", for convenience. Consequently, some software interprets a trailing dot in a domain name to indicate that the domain name is absolute.
An absolute domain name is written relative to the root and unambiguously specifies a node's location in the hierarchy. An absolute domain name is also referred to as a fully qualified domain name, often abbreviated FQDN. Names without trailing dots are sometimes interpreted as relative to some domain name other than the root, just as directory names without a leading slash are often interpreted as relative to the current directory.
...
"
I don't have old book copies any more, I've just this one with me.
At one point we were looking at moving a bunch of separate domains under a single dotless domain, due to the threatened death of 3p cookies, so that cookies could be dropped directly onto the cctld (think "you're logged into the entire TLD"). As the owners of the cctld it felt like a neat use that technically could work but ICANN and other groups are explicitly against that.
I think done well, AOL keywords are actually a good idea.
They could also cut down on the fraudulent websites out there.
Not sure how to fully implement it but given the safe browsing features already implemented in web browsers it could perhaps be part of that. Or a new TLD.
I imagine they'd have all the lovely problems of both EV certs (sure, you're legitimately PayPal Corp, in Malawi) and limited real estate price squeezes.
Curation of "good" or "real" websites has been tried before - I don't envy anyone that wants to try another go at it.
I knew someone who had email ??@ua (two letters masked for priivay) which might have been one of the shortest email addresses in the world. Unfortunately it was not very useful as most email systems failed to recognize it as a valid email address. :(
It's funny seeing that list of MX apex records. In response to me trying to show off how I had acquired a single letter domain, and had a single letter e-mail address (which resulted in *@*.**, replacing asterisks with letters), my boss showed how he was able to receive an e-mail address under one of those two-letter 'MX apex records'...
I used to work with a very gifted old school systems engineer who used to run the network and systems behind a country TLD; I remember him telling me about how he sent an email from the TLD itself out to the world - something that baffled and shocked me as a junior at the time, simply thinking it wasn’t possible.
I had a teacher in high school who once wrote a URL on the whiteboard like this: com/foo/bar.html
Upon informing him that he had forgotten to write the domain, I learned that the site was actually www.com, and he had just left the http://www part off because “the web browser adds that automatically”. I assured him that, while in principle he was more or less correct, but in this case it wouldn’t work. He ended up adding the www, but I could tell he was skeptical that I was just being a smart ass.
Every ten years I fiddle around with DNS and look for these weird names where the top level domain resolves to an actual address.
It's funny to refer to these as "dotless" since you still need a dot, on the end, to "canonize" the name and tell your DNS recursor 'hey, stop appending domains to see if you can find this.'
And, our recent history has "Canonized" a new pope, and you could (maybe?) look it up against one of the few dotless global DNS entries, but it's still going to need the trailing dot to tell your recursor that it's a canonical name...
i remember back in the old days a MX queary for a single letter between 'a' and 'm' would be sent to that root. if they wanted to, they could resolve the response.
i remember having a conversation w/ paul vixie that he had either set it up (or was presenting it as a thought experiment) that he could have the email address "p@f". and i trust paul knew what he was doing with respect to DNS and RFC822 email.
My uncle had one of these in the 90s. All I knew was he was a higher up at the university in his smallish country, and ran their internet stuff. It confused the heck out of me when he verbally told me to bring his website up at Thanksgiving dinner, and after I typed a dot, he said "no no, no dot. just enter" And it worked. Baffled me as a kid. Nice to finally have some explaination for that fever dream of a memory.
1000 requests / min @ 10ms limit / request. That's 16 requests per second. Any reasonable CMS, wiki or blogging tool should be able to do one request in 62.5ms. Add on cacheing for non logged in users and nginx serving anything static, that's less than the power a $5 VPS provides.
At these rates, the case for Cloudflare is a lot less than it was.
Obviously a $5 VPS would give you more raw compute than the Cloudflare Workers free tier.
However:
1. It would run in a single location in the world, whereas Workers (even on the free tier) will run in Cloudflare locations all around the world, close to the end user, reducing latency.
2. If you're going to compare against a $5 VPS, the $5 Workers paid tier is probably a better comparison? It can instantly scale to millions of requests per second.
(Disclosure: I'm the tech lead for Cloudflare Workers.)
That is reasonably fast. We wrote entire games in PHP where we aimed for wall time under 100ms. That is a challenge, but often doable. Some routes managed to respond in under 50ms.
You probably haven't heard of them. We were a German studio, and most of our games only reached a few tens of thousands of players. The biggest hit was Xhodon — it had a bit of a following among World of Warcraft fans. It was a fun time.
Blog posts don’t change much. Even if your rendering code is horrendously slow (though, why?), you can just cache the resulting html and serve it up with each request. Or slap nginx in front of your web server locally and let that deal with the load. ‘Course you’ll need your http headers set correctly, but you needed that anyway for cloudflare.
Your server has to be pretty badly configured for a personal blog to run out of CPU handling requests.
mklepaczewski was probably talking about end-to-end. I.e. the number you see in the network tab for request duration - whereas the pricing will only care about the time that the application is actually doing something.
That basically means it starts after the connection was established by the proxy (cloudflare) and terminates before the response is delivered to the client.
Doing the whole round trip within 65ms is actually pretty challenging, even if you are requesting over the wire. It would mean you have maybe 10-20 Ms to query data from the database and process them to html or json. Any kind of delay while querying the database is going to ruin that.
If you had a 65ms in the application, you would probably get a round trip average of something above 90, likely closer to 150 then 90.
Sure, but this particular case clearly wasn't using cache, that's why the free tier limit for an application was reached. Hence it's highly likely that each request hit a database.
The message would've been different if it was cached.
Cloudflare Workers run in front of cache -- which is generally useful since it allows you to serve personalized pages while still pulling the content from cache, and since Workers can easily run in <1ms and run on a machine you were already going to pass through anyway (the CDN), it doesn't hurt performance. But it also means that the free tier limit of 100,000 requests per day includes requests that hit cache.
This is an Cloudflare Worker issue right now. Although I have no idea what the site is and why does it not work.
Most site, on simple page like CMS or wiki should be static. And serving it from cache even a $5 VPS could do a few hundred page view per second, or 1000+ Request per second. I dont believe HN generate these amount of traffic. From previous note on other HN front page page it is actually much smaller than most expected. Something like IIRC 30K to 50K Page views - over the course of 24 hours.
A $5 vps can handle around 15k req/s with a normal setup (you then hit the limit of what a webserver can serve, maybe up to 35k but then it's really over).
Mind you, at that point you serve more requests slower, before that you don't even notice a latency increase.
Yeah I was thinking of being limited by the pipe of 100mbps rather than CPU. But I just checked on Linode and DO turns out those low cost VPS no longer has this limitations. I guess I need to update my mental model.
Just shows again we really don't need CDN for most things. Just keep it simple.
ICANN does not define SMTP, and the "relevant quote" from SSAC in the article footnotes mentions nothing about it, either.
In fact, RFC5321 makes explicit reference to the possibility of an email address using a TLD as the domain in section 2.3.5.
I mean.. you can use emoji domains right now. They work most places for email. The part I found didn't work so well is emoji usernames on emoji domains. That has poor deliverability.
ICANN, by the way, heavily discourages such domain names, even though it can't actually prohibit them: yes, RFC 5892 explicitly prohibits emoji code points in internationalized domain names but so what? If registrars allow (and many acually do allow) registration of such names that only means that they violate some RFC and they already violate quite a lot of them. Who cares! Just pay the money and we will delegate you whatever names you want.
Some things do definitely try to follow RFC 3986 still, but my feeling is that it’s mostly legacy stuff, and the URL Standard is much more important these days. Though RFCs dealing with URLs will probably still cite it (e.g. RFC 9110, HTTP Semantics, June 2022).
https://url.spec.whatwg.org/#host-parsing, follow step seven.
http://[::ffff:1.1.1.1]/
Sadly, cloudflare does not.
Huh, in many years of web development I never knew that. Thanks!
IP address p.q.r.s is decimal p256^3+q256^2+r*256+s.
Or maybe in your terms it's 256^(0..3) where you can think of it like each dotted component is a symbol (like 0-9 in base 10) where each component is a position digit. Where the right-most element is the "256^0" ("ones") digit, and the left most element is the "256^3" ("16,777,216s") digit.
Remove the dots and concat the binary value for 1.1.1.1 and you get 00000001000000010000000100000001.
Convert that binary value to decimal and you get 16843009.
16843009
They insist on using the “www.vatican.va” only, and my browser’s autocomplete history reflects this.
It's very common and understandable for folks to conflate the Holy See with the Vatican, but they are distinct entities with two different functions and purposes.
If we're discussing the administration/governance of the Church and the organs which make up the Roman Curia, then we're definitely looking at the Holy See. It's the Holy See, not the Vatican, which is a Permanent Observer to the U.N.
But again, if we're looking at any sort of physical presence, it's the Vatican City State. The actual territory that's an enclave and microstate is the Vatican. It's where people live, work, and worship. "The Vatican" is the entity selected for the ".va" ccTLD simply because of the way the rest of the world works. But only a few of those 2nd level domains can properly be considered more "Vatican" than "Holy See".
https://www.vatican.va/siti_va/index_va_en.htm
https://archive.is/MDRWw
DNS lookup and web browser domain lookup are not quite the same. This is the price of a unified input bar.
I never saw what was wrong with having a URL and a search box in the same bar. It was fine, and I knew that whatever I typed into the URL bar would be treated as a URL.
Fast forward a few years, and URLs I type into the bar are not treated as URLs (internal HTTP URLs get rewritten to HTTPS when a server is restarting).
homeserver -> Google
homeserver/ -> http://homeserver/
I was writing an email validator for my project which I'm so excited to announce soon. And my research (some stackoverflow answers) suggested that, yeah, you can have "a@b" as a valid email, as long as there's a one-letter TLD that can have MX records.
Which it seems there can be!
So my email validator is essentially just /^.{1,}@.{1,}$/ ... yay.
Many years ago I managed to get a cctld owner to point their tld MX records at my smtp server, modified postfix to allow empty usernames (even although the RFC allows them, postfix didn't), and successfully had someone send me email to '@tld', in order to win a bet. :) (And it was a 2-letter tld.)
Then the owner of "@" cannot use my site. I'm fine with that.
However, there is absolutely no technical reason that I can think of that precludes u@x. In the end DNS query -> DNS answer. Given that say, PowerDNS has LUA built in, I can make it respond with "my little pony's stable is in {random_country}" - to A record requests, which might make the requester a little queasy!
Bugger standards, they are so 1990s!
I recently came across the 3.ie domain so I guess that's more of a guideline than rule.
In the mid-90s, 3M was a customer of the ISP I worked for. Unable to procure the domain name “3m.com” they settled for the alternate “mmm.com”: mildly hilarious considering their lines of business.
I have a .blue email address and it's amazing how many sites still won't accept it. I keep a spare Gmail account for these.
You can do quite well at this, if you're willing to not restrict yourself to regexes and commit to some amount of hackery. One system I worked on used a simple regex (just what is described here IIRC - assert the existence of an @ sign), plus did an MX check on the domain, plus warned (not errored) if the domain was within 1 or 2 Levenshtein distance of any of a list of most common email domains (yahoo, gmail, etc). Statistically it seems like we saved people a lot of grief with this simple filtering.
People accidentally typing their name in the email field, stuff like that. I've done that.
The problems with your .blue is obviously completely unrelated to the "email.contains('@')" check the poster is doing.
I keep a Gmail for the same reason.
I tried to add a .wiki link to a Reddit profile recently and their filters also say that domain is invalid.
That's absurd, there's a .wiki that's almost definitely in the top 20 most visited websites in Korea, if not higher.
Documented as "subadressing" in RFC 5233, and the default for both sendmail and postfix, amongst others. As such, often 'accidentially' supported by many mail providers even when undocumented. Google didn't introduce them, nor are they 'unconventional'.
https://www.rfc-editor.org/rfc/rfc5233
Possibly these validators are working exactly as intended and don't want you to know which service sold your email to spammers.
Then again maybe spammers are smart enough to strip of the + from email lists they purchase.
Tbh though ideally you would use the most restrictive validation that exists in the mail server. If mail server accepts '@tld' you do too.
That’s why there is a trailing dot you see in NS records for example.
Technically you can put just hostname for CNAME record. Obviously, any clients that don't have that domain as search domain will fail but for internal domain, you could do it.
I'm fairly old guy who did work with DNS about 35 years before retirement and what I recall from the beginning when I was reading my first copy of DNS and BIND somewhat quite soon it came out -92 I think the second chapter which describes DNS root "A null (zero-length" was already there.
So a FQDN (Fully Qualified Domain Name) well known www.google.com the would be www.google.com."" where between the quotation denotes where the DNS root is shown.
However, resolvers don't recognise that syntax. Don't be fooled by
$ host www.google.com.""
www.google.com has address 216.58.209.164 www.google.com has IPv6 address 2a00:1450:4026:802::2004
from the shell as it removes those double quotes. Using single quotes around shows how that fails and you can check it easily.
$ host 'www.google.com.""'
Host www.google.com."" not found: 3(NXDOMAIN)
The way I learned to understand it the dot in DNS name is (it signifies) the DNS-tree separator, not part of the DNS name. A bit like in some languages (Pascal) use semicolon (;) a sentence separator not an end of sentence like it's in C and many it's practise adopted later.
OK, here's an excerpt from DNS and BIND by Cricket Liu & Paul Albitz, O'Reilly ISBN 0-596-10057-6, Fifth Edition 2006 book which I still have a printed copy in my shelf and shows what I'm referring above.
Chapter 2: How Does DNS Work, page 12, text after Figure 2-1 they write:
"Domain Names
Each node in the tree has a text label (without dots) that can be up to 63 characters long. A null (zero-length) label is reserved for the root. The full domain name of any node in the tree is the sequence of labels on the path from that node to the root. Domain names are always read from the node toward the root ("up" the tree), with dots separating the names in the path. If the root node's label actually appears in a node's domain name, the name looks as though it ends in a dot, as in "www.oreilly.com." (It actually ends with a dot—the separator—and the root's null label.) When the root node's label appears by itself, it is written as a single dot, "", for convenience. Consequently, some software interprets a trailing dot in a domain name to indicate that the domain name is absolute.
An absolute domain name is written relative to the root and unambiguously specifies a node's location in the hierarchy. An absolute domain name is also referred to as a fully qualified domain name, often abbreviated FQDN. Names without trailing dots are sometimes interpreted as relative to some domain name other than the root, just as directory names without a leading slash are often interpreted as relative to the current directory.
... "
I don't have old book copies any more, I've just this one with me.
To me it felt very AOL keyword
They could also cut down on the fraudulent websites out there.
Not sure how to fully implement it but given the safe browsing features already implemented in web browsers it could perhaps be part of that. Or a new TLD.
Curation of "good" or "real" websites has been tried before - I don't envy anyone that wants to try another go at it.
You do realize there are not that many two-letter combinations…? :)
You cannot access this site because the owner has reached their plan limits. Check back later once traffic has gone down.
Upon informing him that he had forgotten to write the domain, I learned that the site was actually www.com, and he had just left the http://www part off because “the web browser adds that automatically”. I assured him that, while in principle he was more or less correct, but in this case it wouldn’t work. He ended up adding the www, but I could tell he was skeptical that I was just being a smart ass.
It's funny to refer to these as "dotless" since you still need a dot, on the end, to "canonize" the name and tell your DNS recursor 'hey, stop appending domains to see if you can find this.'
And, our recent history has "Canonized" a new pope, and you could (maybe?) look it up against one of the few dotless global DNS entries, but it's still going to need the trailing dot to tell your recursor that it's a canonical name...
i remember having a conversation w/ paul vixie that he had either set it up (or was presenting it as a thought experiment) that he could have the email address "p@f". and i trust paul knew what he was doing with respect to DNS and RFC822 email.
And then I clicked on the HN to see an archive link and then it worked perfectly.
Jeez, If I am going to build any blog, I am just going to publish to archive.
It seems only a privacy leak tool now.
1000 requests / min @ 10ms limit / request. That's 16 requests per second. Any reasonable CMS, wiki or blogging tool should be able to do one request in 62.5ms. Add on cacheing for non logged in users and nginx serving anything static, that's less than the power a $5 VPS provides.
At these rates, the case for Cloudflare is a lot less than it was.
However:
1. It would run in a single location in the world, whereas Workers (even on the free tier) will run in Cloudflare locations all around the world, close to the end user, reducing latency.
2. If you're going to compare against a $5 VPS, the $5 Workers paid tier is probably a better comparison? It can instantly scale to millions of requests per second.
(Disclosure: I'm the tech lead for Cloudflare Workers.)
[1]: https://www.newyorker.com/video/watch/im-not-a-robot
https://medium.com/the-haven/i-am-worried-about-these-newest...
there a fine line between DDOS from bots and 30k real users accessing your site at the same time
cloudflare do not provide resource for the latter
I spent a colossal amount of my childhood and teens playing browser-based games and have zero regrets!
Blog posts don’t change much. Even if your rendering code is horrendously slow (though, why?), you can just cache the resulting html and serve it up with each request. Or slap nginx in front of your web server locally and let that deal with the load. ‘Course you’ll need your http headers set correctly, but you needed that anyway for cloudflare.
Your server has to be pretty badly configured for a personal blog to run out of CPU handling requests.
That basically means it starts after the connection was established by the proxy (cloudflare) and terminates before the response is delivered to the client.
Doing the whole round trip within 65ms is actually pretty challenging, even if you are requesting over the wire. It would mean you have maybe 10-20 Ms to query data from the database and process them to html or json. Any kind of delay while querying the database is going to ruin that.
If you had a 65ms in the application, you would probably get a round trip average of something above 90, likely closer to 150 then 90.
If you cache the response yourself (or use nginx), the server should be responding to queries in <1ms.
The message would've been different if it was cached.
https://workers.cloudflare.com/
(I'm the tech lead for Workers.)
[1] https://developers.cloudflare.com/workers/platform/limits/#d...
Most site, on simple page like CMS or wiki should be static. And serving it from cache even a $5 VPS could do a few hundred page view per second, or 1000+ Request per second. I dont believe HN generate these amount of traffic. From previous note on other HN front page page it is actually much smaller than most expected. Something like IIRC 30K to 50K Page views - over the course of 24 hours.
Mind you, at that point you serve more requests slower, before that you don't even notice a latency increase.
Just shows again we really don't need CDN for most things. Just keep it simple.