I think people will probably deploy in such a way that clients talk to 80 or 443. But there are a number of ways to get to that outcome, including specifying it in the server configuration, or running behind load balancers or other front-end services. Running everything be default on different ports by default has little bearing on how it gets run in production.
On Sun, Jun 26, 2011 at 12:50 PM, Bryan Taylor <[email protected]> wrote: > If we use something other than 80 for http and/or 443 for https, then > clients will have to know magic numbers for the port and firewall > obstacles will annoy them. I don't see HTTP as something we just happen to > have chosen. We should prefer convention over configuration, and embrace > the conventions of HTTP. > > On 6/26/11 11:13 AM, "Jay Pipes" <[email protected]> wrote: > >>On Sun, Jun 26, 2011 at 3:15 AM, Soren Hansen <[email protected]> wrote: >>> 2011/6/25 Jay Pipes <[email protected]>: >>>> Can you explain why having the *default* port be 80/8080 for HTTP >>>> services would hinder that? Unless I'm mistaken, spinning up servers >>>> on different ports is as simple as specifying a set of test config >>>> files that have ports set for an all-on-one-machine setup? >>> >>> I've heard this sort of argument before, and I've never quite >>>understood it. >>> >>> Yes, our API happens to be built on top of HTTP, but why must that >>> bleed into the choice of port number? I think of port 80 not so much >>> as "the HTTP port", but rather "the www port" (and 8080 as the >>> unprivileged www port). >>> >>> Say we had come up with our own basic, generic protocol, on top of >>> which we'd built the Glance API, Nova API, Swift API, etc... Would you >>> want them to have assigned a single port as well, just because their >>> API's all were encapsulated in the same generic protocol? >> >>If we develop APIs on top of other protocols, I'd expect them to be >>different ports. >> >>All I'm saying is that our services (except for Burrow, which has >>non-HTTP choices) are HTTP services, and since 80 is the default port >>for HTTP, I think it's natural for our services to run on 80. I hear >>the other arguments, though. Just offering my opinion. :) >> >>-jay >> >>_______________________________________________ >>Mailing list: https://launchpad.net/~openstack >>Post to : [email protected] >>Unsubscribe : https://launchpad.net/~openstack >>More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
