On Tue, Sep 28, 2010 at 12:51 AM, Chris Anderson <[email protected]> wrote: > On Mon, Sep 27, 2010 at 6:59 PM, Noah Slater <[email protected]> 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 >
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.
