4 ms·

* Your SSL certificate will be considerably more expensive for a wildcard * URI components have a wider scope of acceptable characters than domains, plus uri e

by konad 16y ago

* Your SSL certificate will be considerably more expensive for a wildcard * URI components have a wider scope of acceptable characters than domains, plus uri escaping e.g. spaces with a %20 * subdomains can be traffic shaped / cluster managed using IP addresses (until you run out if IPs) * URI components can be traffic shaped using internal IPs via your web server * In my experience it's easier to mod-rewrite and pass $1 than a DNS and parse a hostname I remember lots of people going with subdomains that have since switched to URI components, particularly http://news.bbc.co.uk/ http://news.bbc.co.uk/ now goes to http://www.bbc.co.uk/news/ http://www.bbc.co.uk/news/ I would say that it is easier to categorize as one drills down. It is a shame that domains ended up backwards or else it would make more sense - http://uk.co.bbc/news http://uk.co.bbc/news So my personal preference is for URI components

mishmash 16y ago
> * Your SSL certificate will be considerably more expensive for a wildcard Very good point. Went with DigiCert for a wildcard a few years ago and it was in the $400-range compared to ~$100 for a standard cert.
- timpish 16y ago
  Wildcards have come down a lot in price. I think you can get one for about $200 now. I'll probably need one anyway since nearly the entire service is going to be on https
kls 16y ago
Don't forget cross-site scripting if you go with any RIA web apps on the domain. I hate that one, because I would love to put all of my services on services.mydomain.com and get them out of the general app space, but it creates such a pain with scripting that it is not worth it.
- timpish 16y ago
  How is this different with an RIA vs non-RIA web app? You mean like something in Flash or Flex vs HTML? Not sure I get what you mean. Are you saying it's more work for a localized app (coolapp.com/customer1/) to interact with services.coolapp.com than with coolapp.com/customer1/services. And does the latter imply that there would be massive redundancy or can one go about routing queries to avoid that?
  - kls 16y ago
    Yes sorry, RIA is JavaScript to me. I mainly work on web-apps, and they are JavaScript intensive. The security constraints but in say that accessing services.mydomain.com is like accessing yourdomain.com so JavaScript balks at it because it views it a a cross site call. So fir simplicity sake you end up just doing mydomain/services/customer1. It is semantics but I would love to put all of my services on a sub-domain and have browser based JavaScript be able to access it. It would make moving that logical sub domain off to an app server easier as it is a DNS entry as opposed to routing rules for the /services sub folder on the domain. For SaaS it would be a god send because for each client you could set up a virtual host that pointed services.clientdomain.com to the hosted app server and provide managed services for a client with just a simple DNS entry. As it sits now, the client has to set up configurations to forward /services to the managed services. For me and what I do, allowing JavaScript XHR calls within the second level domain would simplify some things. The problem is it assumes trust across a domain and that does not hold true for larger entities, for example say you have bigco.com and it has hr.bigco.com. You really don't want all of the enterprise to be able to access sensitive HR services so that is why you get the current model. I just wish it was configurable per domain.
    - timpish 16y ago
      kls, You've certainly taught me a thing or two. I never knew Javascript had such limitations across (sub) domains. There's an old article on it here: http://radio.javaranch.com/pascarello/2005/12/30/1135962460818.html http://radio.javaranch.com/pascarello/2005/12/30/11359624608...
      - 16y ago
timpish 16y ago
"* In my experience it's easier to mod-rewrite and pass $1 than a DNS and parse a hostname" You lost me there. Can you explain? I like your points in favor of URI components.
- konad 16y ago
  With mod-rewrite the first part of the URI component can get passed as a a parameter to whatever comes next. The alternative is to split the hostname parameter. That doesn't sound like a big deal but here's a convoluted example. http://john.doe.example.com/ http://john.doe.example.com/ http://john.doe.example.net/ http://john.doe.example.net/ http://example.net/john.doe/ http://example.net/john.doe/ Here in the UK we also have the .co.uk as a possibility too.

by konad 16y ago

mishmash 16y ago

> * Your SSL certificate will be considerably more expensive for a wildcard Very good point. Went with DigiCert for a wildcard a few years ago and it was in the $400-range compared to ~$100 for a standard cert.

timpish 16y ago
Wildcards have come down a lot in price. I think you can get one for about $200 now. I'll probably need one anyway since nearly the entire service is going to be on https

kls 16y ago

Don't forget cross-site scripting if you go with any RIA web apps on the domain. I hate that one, because I would love to put all of my services on services.mydomain.com and get them out of the general app space, but it creates such a pain with scripting that it is not worth it.

timpish 16y ago
How is this different with an RIA vs non-RIA web app? You mean like something in Flash or Flex vs HTML? Not sure I get what you mean. Are you saying it's more work for a localized app (coolapp.com/customer1/) to interact with services.coolapp.com than with coolapp.com/customer1/services. And does the latter imply that there would be massive redundancy or can one go about routing queries to avoid that?
- kls 16y ago
  Yes sorry, RIA is JavaScript to me. I mainly work on web-apps, and they are JavaScript intensive. The security constraints but in say that accessing services.mydomain.com is like accessing yourdomain.com so JavaScript balks at it because it views it a a cross site call. So fir simplicity sake you end up just doing mydomain/services/customer1. It is semantics but I would love to put all of my services on a sub-domain and have browser based JavaScript be able to access it. It would make moving that logical sub domain off to an app server easier as it is a DNS entry as opposed to routing rules for the /services sub folder on the domain. For SaaS it would be a god send because for each client you could set up a virtual host that pointed services.clientdomain.com to the hosted app server and provide managed services for a client with just a simple DNS entry. As it sits now, the client has to set up configurations to forward /services to the managed services. For me and what I do, allowing JavaScript XHR calls within the second level domain would simplify some things. The problem is it assumes trust across a domain and that does not hold true for larger entities, for example say you have bigco.com and it has hr.bigco.com. You really don't want all of the enterprise to be able to access sensitive HR services so that is why you get the current model. I just wish it was configurable per domain.
  - timpish 16y ago
    kls, You've certainly taught me a thing or two. I never knew Javascript had such limitations across (sub) domains. There's an old article on it here: http://radio.javaranch.com/pascarello/2005/12/30/1135962460818.html http://radio.javaranch.com/pascarello/2005/12/30/11359624608...
    - 16y ago

timpish 16y ago

"* In my experience it's easier to mod-rewrite and pass $1 than a DNS and parse a hostname" You lost me there. Can you explain? I like your points in favor of URI components.

konad 16y ago
With mod-rewrite the first part of the URI component can get passed as a a parameter to whatever comes next. The alternative is to split the hostname parameter. That doesn't sound like a big deal but here's a convoluted example. http://john.doe.example.com/ http://john.doe.example.com/ http://john.doe.example.net/ http://john.doe.example.net/ http://example.net/john.doe/ http://example.net/john.doe/ Here in the UK we also have the .co.uk as a possibility too.