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