First call to webservice always works. Connection Closed or 403 Access Forbidden Messages Thereafter

[Doug Ferguson]

I am using a webservice client that was created from a WSDL file
in .Net 1.1.

The client ALWAYS works the first time I call it.

The second call returns one of two exceptions. It either returns the
error:
A) The connection has been closed on a receive : Unable to read data
from the transport connection: An existing connection was forcibly
closed by the remote host.
OR B) it gives me a 403 Access Forbidden Error.

Any subsequent attempts always return the 403 error.

I have been working on this for days on end and here is more
information that might be of use.
The header file that comes back from the vendor's website shows they
are running IIS 5.
The original client sent to me was written in VS 2003. I opened it in
VS2003 (.Net 1.1) and it works 100% of the time without any problems.

After I open/upgrade the project in VS 2005 and run it on .Net 2.0, I
get the errors described above. I have to stop debugging and restart
the app to get another message through.

We are using certificates to authenticate and communicating over an
https link (no sniffing allowed).

I have tried overriding the GetWebRequest call with various
combination of the lines below and nothing worked.
webRequest.KeepAlive = false;
//webRequest.Proxy.IsBypassed(webRequest.RequestUri); //
No proxy being used anyway
//webRequest.ProtocolVersion =
System.Net.HttpVersion.Version10;
//webRequest.ServicePoint.Expect100Continue = false;

In the code below, I get a response form the first button click, but
the troubles come on any subsequent clicks.

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

Dim ws As New SomeVendor.WebServiceService()

Dim certPath As String = "somepath\certname.cer"
ws.Url = "https://urladdress"

ws.ClientCertificates.Add(X509Certificate.CreateFromCertFile(certPath))
ws.Timeout = 10 * 60 * 1000
Dim response As String = Nothing
Dim xml As String = "<message>xmlstring</message>"

Try
response =
ws.getFullQuotePremiumWebService(xml)
TextBox1.Text = response
Catch ex As Exception
TextBox1.Text = ex.Message
End Try
End Sub

I would greatly appreaciate any help on this.
TIA
Doug Ferguson

[John Saunders [MVP]]

"Doug Ferguson" <dougf...@gmail.com> wrote in message
news:1189104242....@19g2000hsx.googlegroups.com...

>I am using a webservice client that was created from a WSDL file
> in .Net 1.1.
>
> The client ALWAYS works the first time I call it.
>
> The second call returns one of two exceptions. It either returns the
> error:
> A) The connection has been closed on a receive : Unable to read data
> from the transport connection: An existing connection was forcibly
> closed by the remote host.
> OR B) it gives me a 403 Access Forbidden Error.
>
> Any subsequent attempts always return the 403 error.
>

...

> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
> System.EventArgs) Handles Button1.Click
>
> Dim ws As New SomeVendor.WebServiceService()
>
> Dim certPath As String = "somepath\certname.cer"
> ws.Url = "https://urladdress"
>
> ws.ClientCertificates.Add(X509Certificate.CreateFromCertFile(certPath))
> ws.Timeout = 10 * 60 * 1000
> Dim response As String = Nothing
> Dim xml As String = "<message>xmlstring</message>"
>
> Try
> response =
> ws.getFullQuotePremiumWebService(xml)
> TextBox1.Text = response
> Catch ex As Exception
> TextBox1.Text = ex.Message
> End Try
> End Sub

Doug, one thing that jumps out at me is that you're not calling Dispose on
your proxy instance. SoapHttpClientProtocol derives from IComponent which
derives from IDisposable. You should be wrapping the instance in a Using
block:

Using ws As New SomeVendor.WebServiceService()
' etc
End Using

There could be some resource not getting cleaned up that could be causing
the connection to fail on subsequent calls.
--
--------------------------------------------------------------------------------
John Saunders | MVP - Windows Server System - Connected System Developer

[Doug Ferguson]

On Sep 7, 2:06 pm, "John Saunders [MVP]" <john.saunders at
trizetto.com> wrote:
> "Doug Ferguson" <dougfer...@gmail.com> wrote in message

> ---------------------------------------------------------------------------­-----
> John Saunders | MVP - Windows Server System - Connected System Developer- Hide quoted text -
>
> - Show quoted text -

Thanks for your help John.

I have tried setting ws to nothing, calling ws.Dispose, even calling
the garbage collector afterwards to force a clean up. None of those
items worked.
Per your suggestion, I just put in a using statement, but
unfortunately that did not do the trick either. I left in the using
clause for good measure though.

My latest run at it was to leave the original project in VS2003, build
it as a dll, and reference the dll from my VS2005 project. (I'm
willing to try anything at this point.) I added a public interface to
it that accepts the xml request, takes care of all the communications
internally, and returns the result. It yielded the same results as
before.

Do you have any other suggestions I could try?

Thanks Again,
Doug Ferguson

[John Saunders [MVP]]

"Doug Ferguson" <dougf...@gmail.com> wrote in message

news:1189202145.8...@57g2000hsv.googlegroups.com...

Thanks Again,
Doug Ferguson

---------
Doug, I just realized that the 403 error you're getting is not from your web
service. It's from IIS, or maybe ASP.NET. I don't know how that will help
you, beyond saving you the trouble of looking further at the web service.

The only other suggestion I have is to look in the Windows event log on both
the client and server machines to see if there's anything interesting there.
Also, maybe there's some clue in the details on the wire. Look carefully at
the messages being exchanged, using a tool like Microsoft Network Monitor or
TcpTrace (http://www.pocketsoap.com).
--
--------------------------------------------------------------------------------

[Doug Ferguson]

Hi John,

I don't see anything in my logs, but I have asked the vendor to check
their server logs to see exactly what type of 403 error is being
returned. I am also looking at the network traffic to see if I can
recognize anything out of the ordinary between the two calls.
Hopefully, one of these will give me a clue where to look next.

The thing I can't understand though is why the client works 100% of
the time from a .Net 1.1 client, but it consistently has errors with
2.0 (using the exact same client code). It seems to me that there
must be something going on with the new way that 2.0 handles the
connection, or perhaps that something has changed with the way it
handles the certficates.

Thanks Again,
Doug Ferguson

[John Saunders [MVP]]

"Doug Ferguson" <dougf...@gmail.com> wrote in message

news:1189449242.8...@g4g2000hsf.googlegroups.com...
> Hi John,

>
> The thing I can't understand though is why the client works 100% of
> the time from a .Net 1.1 client, but it consistently has errors with
> 2.0 (using the exact same client code). It seems to me that there
> must be something going on with the new way that 2.0 handles the
> connection, or perhaps that something has changed with the way it
> handles the certficates.

That's exactly why I said to look at the network traffic...

[Doug Ferguson]

Hi John,

I followed your suggestion and looked at the network traffic. I could
see that there was a difference in the communication between requests,
but I could not figure out how to use that information.

We finally got the issue resolved with the help of MS tech support.
For the benefit of others, here is what happened:

It turns out we had two distinct problems, one causing the 403 error
and the other causing the connection closed error.

The first thing we did was setup a trace log to determine exactly what
the 403 error was. A description of this is found at
http://blogs.msdn.com/feroze_daud/archive/2005/05/12/416922.aspx.

After examing the log, we found that the 403 error was actually a
403.13 Certificate Revoked Error. In our case, the certificate was
NOT revoked, but that was what was coming back.

We then went through the steps outlined in the following article
http://support.microsoft.com/kb/294305 that explains the cause and
resolution of getting Revoked messages when the certificate was still
valid.

We also tried the following: http://support.microsoft.com/?id=841641

I don't know if either of these steps wsa necessary, but if so, they
were not sufficient to resolve our problem.

We stopped getting the 403.13 error after implenting the steps found
in http://support.microsoft.com/kb/823177. The 403.13 errors were
getting returned because the url listed on the certificate did not
match the url we were using to access the site. This is something
that .Net 2.0 checks, but not 1.1. I have no idea why the request
would always work the first time on 2.0, but the info in the KB
article is what fixed it.

After this change we received the connection closed error 100% of the
time on any request after the first.

As for our connection closed issue, the client was authenticating with
the server the first time it sent a request. On subsequent requests,
the client was trying to use the same session ID it had negotiated the
first time. The server timed the session out and refused the ID the
client was sending. The solution was to have the client always
renegotiate the ssl handshake for each request. This is described in
http://support.microsoft.com/?id=247658.

This is definitely something I would not have figured out on my own.

Thanks again for your help John.

Thanks also to Prashant Phadke at Microsoft tech support
Doug Ferguson