> > > The lack of IPv6 literal address support in the version of wininet.dll > > > that shipped with Windows XP was for reasons of engineering > > > expediency, > > > > in other words, MS deliberately shipped a broken product. > > Oh, look, release notes, known issue statements, bugtracker entries... > > Seems like everybody is deliberately shipping broken products...
Yeah, I was chastised in private mail for shooting the messenger, and appropriately so. It is a bit difficult for me to understand how support for address literals could be considered such a low priority that it could be omitted from a shipping product. Recently when I wrote an app that used v6 and urls, the first routine I wrote was one that would take either an address literal or a DNS name, plus a port number, and return a properly filled-in sockaddr structure (no, getaddrinfo by itself isn't sufficient), and the second one I wrote was one that would parse a URL and extract either a DNS name or address literal from that. Writing both routines, and the test cases, and testing the routines on several different platforms took about 2 hours. Admittedly I'm a bit biased. I've measured the percentage of email delivery failures due to various reasons and discovered that DNS misconfiguration was high on the list (MTA miscnfiguration was also high). I've also attempted to measure the amount of delay caused by DNS lookups. So I understand better than most why it's important - for both diagnostic and performance reasons - to support address literals. That and I suspect there's a philosophical difference in writing APIs. I believe in thinking hard about what an API needs to do before writing it, so that the API once implemented will be able to be used for a wide set of purposes. That and I try hard to only have to implement the API once, because the overhead in context switching my brain back to the API when I need to add functionality to it is almost certainly larger that the effort required to completely implement the API the first time. If it's too difficult to implement it completely, there's probably something wrong with the design. I do understand and use stubbing, but I regard that as a technique to be used for quick prototypes that are going to be discarded anyway. I also understand the notion of biasing the testing toward the most frequently-used features on the assumption that such testing will uncover the most common bugs. But there are important features that are not frequently used, and there are bugs that are important to fix even though they are in seldom-used code. Features used for diagnostics, and security bugs are good examples of these. Then there's the problem that when a 800-pound gorilla ships code, that code largely defines expectations for what will and will not work in practice - often moreso than the standards themselves. So if MS ships code that doesn't support address literals, then nobody will attempt to use address literals unless they can detect that the client isn't using MS code. For this and other reasons, I believe that 800-pound gorillas have a greater responsibility than their competitors to ship code that works properly. OTOH, servers that take the trouble to recognize that the client isn't a MS client can provide their clients with significantly better response time by giving those clients address literals in internal references (either in HTTP referrals or in HTML).
