I've been doing some experiments on what effect the DNS changes have on
Axis and the .NET (WSE2.0) stack; notes are up on :
http://www.iseran.com/Steve/blog/ ; I'll try and pull it into more of a
proper article one evening next week.

Essentially both stacks bail out with unhelpful error messages at the
302 redirect sent back from the spoof http server that appears at every
invalid .com address. This redirect is sent back *after* the post, so
you end up posting everything once before getting to the brick wall.
Everything breaks properly; the only issue is that the response codes
are not obviously 'wrong endpoint'. Do you want to deal with customers
saying they keep getting '302(found)' messages from Axis or
"System.InvalidOperationException: Client found response content type of
'text/html; charset=iso-8859-1', but expected 'text/xml'" from the .NET
stack?


We could fix axis to recognise this specific situation
-error code = 302
-location header = sitefinder.verisign.com
and map it into a java.io.UnknownHostException to throw upstream; apps
may make better sense of this.

What we cannot do easily is recognise trouble at anything other than
port 80; hitting an endpoint http://invalidname.com:8080/ is going to
result in a connection refused error instead.

Thoughts? How do other stacks react to the 302+text/html responses?


-Steve