axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bhushan Khanal <bhush...@wrq.com>
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 [mailto:sanjiva@watson.ibm.com] 
Sent: Monday, September 29, 2003 12:11 PM
To: axis-dev@ws.apache.org
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 whatevername.com
and see whether its the same as sitefinder.versign.com. If so we
can properly complain about any port #.

Sanjiva.

----- Original Message -----
From: "Steve Loughran" <steve_l@iseran.com>
To: <axis-dev@ws.apache.org>
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 :
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.
>

Mime
View raw message