3 ms·

It's pretty common practice for a .com to run its backend stuff on the .net version of their .com domain. Also, if you know how CDNs tend to structure their DN

It's pretty common practice for a .com to run its backend stuff on the .net version of their .com domain. Also, if you know how CDNs tend to structure their DNS entries for their clients, you can remove all but seven of those entries from the list.

prawn 11y ago
No average joe is going to know any of that though. If they saw or heard about that list, they'd be confused or freak out.
- jdmichal 11y ago
  They would only freak out because some tech person is presenting the information to them in a way that makes them think they should.
  - prawn 11y ago
    Tech people are the first ones to freak out about it. ;)
    - simoncion 11y ago
      A non-technical person's computer is often a source of agitation for a wide variety of reasons. Sometimes those reasons are reasonable. Sometimes they are not. I don't think we're doing ourselves any favors by speculating what Aunt Tilly might think of a long list of human-unfriendly domain names.
viewer5 11y ago
> It's pretty common practice for a .com to run its backend stuff on the .net version of their .com domain. Meaning the .com is basically just the UI that sends all its information to the .net to be processed, then back to the .com to be rendered? What's the benefit of that to the company, instead of having it all on the .com site?
- simoncion 11y ago
  > Meaning the .com is basically just... Sort of, yeah. I can't tell you why you'd want to have a front office/back office split like that, but I could speculate: Domains are cheap, and it might reduce cognitive overhead to have a .com/.net operational split.
  - iancarroll 11y ago
    Part of it is removing extra data when requesting style sheets and such - there's no need for a browser to send all of the set cookies it has for your web application when it's fetching styles, so people buy separate domains for them.
    - simoncion 11y ago
      I'm not a web dev, so pardon my ignorance. Setting cookies for one third-level subdomain[0] and serving assets from another still sends all of the cookies across when fetching the assets? [0] e.g. cookie.example.com and assets.example.com
      - iancarroll 11y ago
        The problem is you can't explicitly tell a browser to fetch a cookie from cookie.example.com - and when you have multiple subdomains which rely on the cookie, plus analytics software which sets it for the whole domain, you can't do that.
        simoncion 11y ago
        The following isn't snark: So, is that a "yes" to my question? A "sort of"? A "it's too complicated to summarize"?
        iancarroll 11y ago
        Sort of: If you only ever need a cookie set on app.example.com, you can do that and use assets.example.com. It'll work for simple applications and not much else. Things like Google Analytics also set cookies by default on *.example.com so you'll have to figure out a way around that.

prawn 11y ago

No average joe is going to know any of that though. If they saw or heard about that list, they'd be confused or freak out.

jdmichal 11y ago
They would only freak out because some tech person is presenting the information to them in a way that makes them think they should.
- prawn 11y ago
  Tech people are the first ones to freak out about it. ;)
  - simoncion 11y ago
    A non-technical person's computer is often a source of agitation for a wide variety of reasons. Sometimes those reasons are reasonable. Sometimes they are not. I don't think we're doing ourselves any favors by speculating what Aunt Tilly might think of a long list of human-unfriendly domain names.

viewer5 11y ago

> It's pretty common practice for a .com to run its backend stuff on the .net version of their .com domain. Meaning the .com is basically just the UI that sends all its information to the .net to be processed, then back to the .com to be rendered? What's the benefit of that to the company, instead of having it all on the .com site?

simoncion 11y ago
> Meaning the .com is basically just... Sort of, yeah. I can't tell you why you'd want to have a front office/back office split like that, but I could speculate: Domains are cheap, and it might reduce cognitive overhead to have a .com/.net operational split.
- iancarroll 11y ago
  Part of it is removing extra data when requesting style sheets and such - there's no need for a browser to send all of the set cookies it has for your web application when it's fetching styles, so people buy separate domains for them.
  - simoncion 11y ago
    I'm not a web dev, so pardon my ignorance. Setting cookies for one third-level subdomain[0] and serving assets from another still sends all of the cookies across when fetching the assets? [0] e.g. cookie.example.com and assets.example.com
    - iancarroll 11y ago
      The problem is you can't explicitly tell a browser to fetch a cookie from cookie.example.com - and when you have multiple subdomains which rely on the cookie, plus analytics software which sets it for the whole domain, you can't do that.
      - simoncion 11y ago
        The following isn't snark: So, is that a "yes" to my question? A "sort of"? A "it's too complicated to summarize"?
        iancarroll 11y ago
        Sort of: If you only ever need a cookie set on app.example.com, you can do that and use assets.example.com. It'll work for simple applications and not much else. Things like Google Analytics also set cookies by default on *.example.com so you'll have to figure out a way around that.