Hello, CouchDB is a document database that implements a RESTful JSON API via HTTP. All interaction between the server and client is made via standard HTTP 1.1 responses and requests. The database only makes use of standard HTTP 1.1, and does not add any features.
While CouchDB speaks vanilla HTTP, just like a WWW server on TCP 80, it does so in a constrained manner. The specific URLs exposed, and database-specific consequences of using a GET or a POST request (for example) are formalised for client and server. Additionally, CouchDB only exposes an API via HTTP. It does not serve up web pages for human consumption. TCP 80 is reserved for uses of HTTP that serve up World Wide Web pages. These two use-cases for HTTP a quite different, and call for different ports. Many CouchDB users want to install a WWW server on a host, at the same time as a CouchDB server. While both server daemons speak the same network protocol, they both have very different uses. And both daemons cannot listen on the same port for connections. And just like one might want to host a MySQL database server on the same host as an Apache WWW server, many people want to host a CouchDB database server too. And just like MySQL has TCP allocated 3306 for this, CouchDB has TCP 5984. The problem we're having now is that users want to run a CouchDB database server with newly enabled TLS/SSL feature. Because of the way HTTP 1.1 works with TLS/SSL, you cannot listen for secure connections on the same port as non-secure connections. This is because the WWW server must know the host before the proper secure handshake can be initiated. Upgrading to TLS/SSL within a regular HTTP 1.1 request would have fixed this problem, but this was never properly implemented by many clients. To solve this problem, most WWW servers additionally listen on a new hostname and TCP 443 combination for each TLS/SSL site they accept connections for. It is the only interoperable way to accept secure and non-secure connections at the same time. Because CouchDB is a non-WWW HTTP 1.1 server that requires the ability to serve secure and non-secure connections from the same host, it is therefor requested that a secure port be allocated, so that the same solution as WWW HTTP 1.1 can be implemented. Thank you, Noah
