couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb:
Date Tue, 28 Sep 2010 01:59:45 GMT

On 28 Sep 2010, at 02:18, Paul Davis wrote:

> Multiple public interfaces and binding ssl to a subset? What does it
> matter why so much as "not obviously unpossible". In the land of "not
> obviously unpossible" as long as we don't have different semantics on
> what's served to any given port, then an idea of "the right one" is
> rather unimportant and fairly client specific, ie, "the only public
> interface I have access to."

I'm not sure I see where the confusion is.

I am not suggesting this feature is badly thought out.

I'm just trying to clarify how it will work.

There are four possibilities.

A file with a single HTTP URL in it:


A file with a single HTTPS URL in it:


A file with a HTTP and HTTPS URL in it:


A file with multiple URLs for each protocol in it:


The first three are okay and I see no problem with them.

For the last one, it boils down to the following two question:

 * Do the port 80 URLs *always* point to the same thing?
 * Do the port 443 URLs *always* point to the same thing?

If the answer is yes to both of those questions, and WILL be yes forever, then I see no problem
with adopting this format. If the answer is no, or might be no, then I suspect we need to
rethink it. If they could point to different things, and we have no way of indicating what
they point to, that would render the file almost useless. I know my question might come across
as utterly stupid, but I want to make sure that whatever format we choose is going to be future
View raw message