Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

foo@bar.com

bar.com

Post reply on HN
Print view View original

151–160 of 301 posts

Re: foo@bar.com

#151

Post by CydeWeys »

captn3m0 wrote: post #128
CydeWeys wrote: post #80

Earlier quoted context omitted.

.app, .dev, .prod, and .zip all had substantial volume of problematic traffic that was discovered during the Controlled Interruption period (which occurs prior to launch and consists of a wildcard DNS entry placed on the entire TLD). You would not believe some of the brokenness that was happening there. .zip may need some explanation -- apparently there are lots of library API calls out there that take a path string…

ICANN should never have assigned .zip, there's just too much potential for abuse, confusion giving away a common extension as a TLD.

There's a lot of overlap between file extensions and TLDs though. .py, .sh, and .app are some more examples (but a fully exhaustive list would be in the dozens if not hundreds). At some point you have to just treat them as the separate namespaces that they actually are (and not somehow try to block a TLD from being used as a file extension, or vice-versa).

Besides, accidentally resolving a file extension to a TLD is only one of many possible different serious errors that can result from exposing an API that can load files locally or remotely, and thus make network calls that you might not be expecting. Fundamentally you need to fix that API either way.

Re: foo@bar.com

#152

Post by johnzim »

captn3m0 wrote: post #128
CydeWeys wrote: post #80

Earlier quoted context omitted.

.app, .dev, .prod, and .zip all had substantial volume of problematic traffic that was discovered during the Controlled Interruption period (which occurs prior to launch and consists of a wildcard DNS entry placed on the entire TLD). You would not believe some of the brokenness that was happening there. .zip may need some explanation -- apparently there are lots of library API calls out there that take a path string…

ICANN should never have assigned .zip, there's just too much potential for abuse, confusion giving away a common extension as a TLD.

We just never should have allowed filename extensions to have semantic power. Resource forks are far more elegant and you could do simple look ahead checks to verify types etc.

Re: foo@bar.com

#153

Post by dan-robertson »

CydeWeys wrote: post #146
basch wrote: post #138

Earlier quoted context omitted.

or go back to left to right reading. http//com.google.www. vs http//com.google.www./file.zip

This is the real answer here. It's widely believed that domains working the opposite way of filesystem hierarchies and even URL paths was a huge design mistake. Think of how many billions of dollars have been lost over the years from account compromises resulting from people not correctly distinguishing yourbank.com/account/foobar from yourbank.com-account.info/foobar.

1. The reason for the change is generally thought to be email: you read least specific to most specific from left to right, like non-American dates, e.g firstname.lastname@group.department.university.edu

2. also I think ! was used rather than . for some networks at some times. Certainly I’ve heard this anecdote from some early users of the internet (or maybe other computer networks)

3. Traditionally the dot is the zero-level or extra-top level domain, a bit like / for root in the Unix file system. Indeed if you use dig you may be familiar that it writes domains like “www.google.com.” My web browser only partly seems to accept this format.

Re: foo@bar.com

#154

Post by divbzero »

divbzero wrote: post #148

What I’m curious to learn is which mail server he uses to handle the influx of emails to foo@bar.com…

Looks like at the moment he simply lets them drop:

  $ dig -t MX bar.com +short
  $

Re: foo@bar.com

#155

Post by oauea »

BiteCode_dev wrote: post #144
Ekaros wrote: post #137

Earlier quoted context omitted.

Or if browsers weren't trying to be too smart enough and use the same box for both searching and addresses. Trips me with .py files all time time.

After ".py", use " ?" (the space is important) to force the search in firefox.

Or just start the query with `?`

Typing `?bla.py` in the omnibar will perform a search for `bla.py` on both Firefox and Chrome

Re: foo@bar.com

#156

Post by kbenson »

BiteCode_dev wrote: post #144
Ekaros wrote: post #137

Earlier quoted context omitted.

Or if browsers weren't trying to be too smart enough and use the same box for both searching and addresses. Trips me with .py files all time time.

After ".py", use " ?" (the space is important) to force the search in firefox.

Using a question make in front of the term is traditionally how some browsers trigger search. They usually have a jeybconbe to add it automatically.

For example, in firefox and chrome ctrl-l will clear the URL bar and put the cursor and focus there to take you to the location you enter, and ctrl-k will do similar but pre-fill the location bar with a preceding '?' so a search is triggered on the input.

These shortcuts have existed for quite a while. They used to just focus the respective separate input boxes, when it wasn't all done through one.

Re: foo@bar.com

#157

Post by oauea »

CydeWeys wrote: post #53
jbrooksuk wrote: post #42

Earlier quoted context omitted.

Out of interest, how did this happen without any investigation into possible consequences etc? It’s a huge change that surely warranted special attention before making it happen?

It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes. So yes, we did…

Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google.

I've always hated Google for egoistically claiming this tld, and ICANN for letting them.

Re: foo@bar.com

#158

Post by datameta »

Chirael wrote: post #139

I’ve always wondered if “foo” and “bar” was specific to a certain (now older) generation of programmers and would eventually fade into obscurity. Or has that bit of programmer culture been passed on to newer generations too?

Afaik 'foo' and 'bar' still tend to be a commonly used example variable/function/data structure name by older practitioners of C and C++ in academia so I do wonder if it will pass on...

Re: foo@bar.com

#159

Post by jrockway »

captn3m0 wrote: post #128
CydeWeys wrote: post #80

Earlier quoted context omitted.

.app, .dev, .prod, and .zip all had substantial volume of problematic traffic that was discovered during the Controlled Interruption period (which occurs prior to launch and consists of a wildcard DNS entry placed on the entire TLD). You would not believe some of the brokenness that was happening there. .zip may need some explanation -- apparently there are lots of library API calls out there that take a path string…

ICANN should never have assigned .zip, there's just too much potential for abuse, confusion giving away a common extension as a TLD.

I think it's okay. They are different namespaces and people should fix their bugs. It would be like skipping the street number "911 Foo St." because "911" is the emergency phone number and 911 Foo St. is just a regular house. I'm sorry if someone is confused but they shouldn't be confused. They're totally different things.

The biggest mistake we made with DNS was the "shortcut" of implicitly adding the root domain to random strings treated as domain names (turning "example.com." into "example.com"). The file "foo.zip" and the website "foo.zip" wouldn't even be ambiguous if we called the website "foo.zip.". "ndots" also causes operators of DNS servers a lot of pain -- some malfunctioning program tries to resolve "example.invalid" in a tight loop and it balloons to asking for "example.invalid.", "example.invalid.local.", "example.invalid.cluster.local.", "example.invalid.svc.cluster.local.", and then DNS blows up, breaking everything.

Re: foo@bar.com

#160

Post by [deleted] »

Ekaros wrote: post #137
jdxcode wrote: post #130

Earlier quoted context omitted.

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

Or if browsers weren't trying to be too smart enough and use the same box for both searching and addresses. Trips me with .py files all time time.

[deleted]
Post reply on HN