Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 90840 invoked from network); 28 Sep 2010 05:06:03 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Sep 2010 05:06:03 -0000 Received: (qmail 6878 invoked by uid 500); 28 Sep 2010 05:06:02 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 6676 invoked by uid 500); 28 Sep 2010 05:06:01 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 6668 invoked by uid 99); 28 Sep 2010 05:06:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Sep 2010 05:06:00 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.214.180 as permitted sender) Received: from [209.85.214.180] (HELO mail-iw0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Sep 2010 05:05:55 +0000 Received: by iwn8 with SMTP id 8so7382075iwn.11 for ; Mon, 27 Sep 2010 22:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=yWc+DPkWva9ljgCmAj6etkQjnI0nc4xyqtQU5GHzZmU=; b=FJ1a3/zZoo+8zgBTrn5AF13V3ORvDLdmsapyg6KOLvItl5HOSmd5tfpOLuqMxE9lrY mGFfzeTY6ym2uIQjmsYvRaYE9nKlhPiniBPh7kkRhEfajdy/ivsONrrl4/PU89BlG7oH 8J6urlhK8xEfMCcTL6LVQjUayjwUgy/rNVySs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=EECxVxFFeX+PeCB/pVQ38vJ+VtYIw6Ll8jtsycEyZX2qvWDniyUuRCK5nt3IoxJIvA VHx/UBV5LODlHMrmMNyx1hdnqkYjtk/sgHi5MuTZKUBsSIq9LEU+C8JijPushowcxVUs mbuu6P+gAPkb/HW+Q8t5JmjCV91QIKg22jsHk= Received: by 10.231.148.85 with SMTP id o21mr10373284ibv.26.1285650331886; Mon, 27 Sep 2010 22:05:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.194 with HTTP; Mon, 27 Sep 2010 22:04:51 -0700 (PDT) In-Reply-To: References: <20100925173757.C583A23889ED@eris.apache.org> <79D74715-4889-4613-BEE3-B7905EDA6532@apache.org> <3069D1E0-AB30-4B11-A5F7-F2A8FA9E6625@apache.org> From: Paul Davis Date: Tue, 28 Sep 2010 01:04:51 -0400 Message-ID: Subject: Re: svn commit: r1001283 - in /couchdb/trunk/etc/couchdb: Makefile.am default.ini.tpl.in To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 28, 2010 at 12:51 AM, Chris Anderson wrote: > On Mon, Sep 27, 2010 at 6:59 PM, Noah Slater 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: >> >> =A0* Do the port 80 URLs *always* point to the same thing? >> =A0* 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 d= ifferent 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 i= s going to be future proof. > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > More specifically, the URL scheme needs to reflect the protocol. Once that exists I think we've exhausted our duty because we can tell clients "these are the endpoints" and they'll figure out which ones are reachable and compatible.