axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bhushan Khanal <>
Subject RE: Verisign DNS changes and impact on web services
Date Mon, 29 Sep 2003 19:41:54 GMT
Unless this has been fixed recently, I have also found that Axis client does
not deal with 100 Continue very well. Does any one know where Basic Profile
1.0 stands on HTTP 100 Continue?

Bhushan Khanal

-----Original Message-----
From: Sanjiva Weerawarana [] 
Sent: Monday, September 29, 2003 12:11 PM
Subject: Re: Verisign DNS changes and impact on web services

+1 .. I agree that this is an ugly hack to fix and even uglier
bit of marketing by Verisign.

We could do one step further- check the IP address for
and see whether its the same as If so we
can properly complain about any port #.


----- Original Message -----
From: "Steve Loughran" <>
To: <>
Sent: Saturday, September 27, 2003 1:07 AM
Subject: Verisign DNS changes and impact on web services

> I've been doing some experiments on what effect the DNS changes have on
> Axis and the .NET stack; notes are up on :
> 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 =
> and map it into a 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 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.

View raw message