5 ms·

> 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 send

by 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.

5 ms·

> 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 send

by viewer5 11y ago

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.