couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in
Date Tue, 28 Sep 2010 04:51:16 GMT
On Mon, Sep 27, 2010 at 6:59 PM, Noah Slater <nslater@apache.org> wrote:
>
> 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:
>
>> http://192.168.0.10:80/
>
> A file with a single HTTPS URL in it:
>
>> http://192.168.0.20:443/
>
> A file with a HTTP and HTTPS URL in it:
>
>> http://192.168.0.10:80/
>> http://192.168.0.20:443/
>
> A file with multiple URLs for each protocol in it:
>
>> http://192.168.0.10:80/
>> http://192.168.0.11:80/
>> http://192.168.0.12:80/
>> http://192.168.0.20:443/
>> http://192.168.0.21:443/
>
> 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?
>

I guess I assumed they would always be the same. more realistically I
see the file could have these contents:

http://192.168.0.10:80/
http://192.168.0.10:5984/
https://192.168.0.10:443/
https://192.168.0.10:8889/

Does that make more sense? I think the protocol needs to be specified
because what if you want to run https on a non 443 port?

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



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message