Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <3F748E57.3000606@iseran.com>
Date: Fri, 26 Sep 2003 12:07:03 -0700
From: Steve Loughran <steve_l@iseran.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701
MIME-Version: 1.0
To: "axis-dev@ws.apache.org" <axis-dev@ws.apache.org>
Subject: Verisign DNS changes and impact on web services
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


I've been doing some experiments on what effect the DNS changes have on 
Axis and the .NET stack; notes are up on : http://www.iseran.com/Steve/blog/

essentially both 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?


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; this 
may be more meaningful.

This would be an ugly hack, but what verisign have done is an even 
uglier hack.

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.

Maybe we should just make sure the full endpoint URL goes into the 
fault, so that people can look at it easily.