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