PBM: SoapClient message not sent when web service implemented as a IIS web site

[Vince C.]

Hi.

We've setup a W2K server with IIS. Soap Toolkit 3.0 is installed on the server.
The server is targeted to host several webs that must all be able to send soap
messages. HTTP headers are used to distinguish target web service calls.

We've then defined a new web site.The latter contains a subfolder in which a web
service is implemented as an ASP page using low level API. Anonymous access has
been disabled on the web service so that people accessing it are authenticated
sing either Kerberos or Integrated security.

We've noticed using a TCP trace tool that a SOAP client, which is designed to
use SoapClient30 object, does not send any SOAP message when anonymous access is
disabled on the web service folder. Meanwhile the client keeps receiving HTTP
401 responses - unauthorized.

When we do exactly the same on a Windows 2000 Pro, everything runs fine, just as
expected. No significant differences are seen in HTTP headers between W2K pro
and W2K server.

Does anybody have an idea?

Thanks a lot in advance,
Vince C.

 

[Frank Mantek]

Need more information here...

We've noticed using a TCP trace tool that a SOAP client, which is designed to
use SoapClient30 object, does not send any SOAP message when anonymous access is
disabled on the web service folder. Meanwhile the client keeps receiving HTTP
401 responses - unauthorized.

That soapclient is living where ? Is it using the highlevel api ? What does
that mean it does not send a message ?

Regards

Frank Mantek

 

[Vince C.]

Need more information here... [...]
That soapclient is living where ?

I've made tests on the local server machine where the service resides and from a
distinct client machine talking with the remote server.

Is it using the highlevel api ?

I've written in my post the client is using SoapClient30 so I was talking about
hi-level API of course...

What does that mean it does not send a message ?

That the SOAP message (the whole XML stream) does not appear in the TCP trace
tool window. Should I have written it differently?

What happens is the server receives only part of the whole HTTP message. It
receives HTTP headers but no content. Besides it immediately sends a HTTP status
401 (unauthorized). The client never sends the expected SOAP message as if it
didn't understand it has to authenticate.

We've made further tests with a SoapClient30 object (hence hi-level API). If we
set Connector Properties "AuthPassword" and "AuthUser" to adequate user/pwd
values in the script where the SoapClient30 object is used, the message is sent
as expected and everything runs fine. If we don't set these properties, the Soap
message exchange fails as described in my previous post.

Again this erratic behaviour occurs only in IIS on a W2K server and if the web
service runs on a IIS Web. If it runs in a IISWebFolder, everything is fine.

See my post
http://www.talkaboutsoftware.com/group/microsoft.public.xml.soap/messages/4888.html
dated April 13th this year about the same problem. It is not my first post about
it.

Vince C.

 

[Vince C.]

Hi Frank.

May I have any follow-up on this problem?

Vince C.

Need more information here... [...]
That soapclient is living where ?

I've made tests on the local server machine where the service resides and from a
distinct client machine talking with the remote server.

Is it using the highlevel api ?

I've written in my post the client is using SoapClient30 so I was talking about
hi-level API of course...

What does that mean it does not send a message ?

That the SOAP message (the whole XML stream) does not appear in the TCP trace
tool window. Should I have written it differently?

What happens is the server receives only part of the whole HTTP message. It
receives HTTP headers but no content. Besides it immediately sends a HTTP status
401 (unauthorized). The client never sends the expected SOAP message as if it
didn't understand it has to authenticate.

We've made further tests with a SoapClient30 object (hence hi-level API). If we
set Connector Properties "AuthPassword" and "AuthUser" to adequate user/pwd
values in the script where the SoapClient30 object is used, the message is sent
as expected and everything runs fine. If we don't set these properties, the Soap
message exchange fails as described in my previous post.

Again this erratic behaviour occurs only in IIS on a W2K server and if the web
service runs on a IIS Web. If it runs in a IISWebFolder, everything is fine.

See my post
http://www.talkaboutsoftware.com/group/microsoft.public.xml.soap/messages/4888.html
dated April 13th this year about the same problem. It is not my first post about
it.

[...]

 

[Frank Mantek]

Did you debug your service to see if you are even getting called, of if you
have a normal security issue (my bet, as all you are changing is the hosting
environment, and there is nothing i can remember from the top of my head
that should be different in our code in that respect).

The headers are send, the server figures request denied due to security,
soap never get's called. The described behaviour fits nicely with standard
security failures.

Frank

Hi Frank.

May I have any follow-up on this problem?

Vince C.

"Frank Mantek" <[email protected]> a écrit dans le message de

Need more information here... [...]
That soapclient is living where ?

I've made tests on the local server machine where the service resides

and from
a

distinct client machine talking with the remote server.

I've written in my post the client is using SoapClient30 so I was

talking

about
hi-level API of course...

That the SOAP message (the whole XML stream) does not appear in the TCP trace
tool window. Should I have written it differently?

What happens is the server receives only part of the whole HTTP message. It
receives HTTP headers but no content. Besides it immediately sends a

HTTP

status
401 (unauthorized). The client never sends the expected SOAP message as if it
didn't understand it has to authenticate.

We've made further tests with a SoapClient30 object (hence hi-level

API). If
we

set Connector Properties "AuthPassword" and "AuthUser" to adequate user/pwd
values in the script where the SoapClient30 object is used, the message

is

sent
as expected and everything runs fine. If we don't set these properties,

the

Soap
message exchange fails as described in my previous post.

Again this erratic behaviour occurs only in IIS on a W2K server and if the web
service runs on a IIS Web. If it runs in a IISWebFolder, everything is fine.

See my post

http://www.talkaboutsoftware.com/group/microsoft.public.xml.soap/messages/4888.html

dated April 13th this year about the same problem. It is not my first

post

about
it.

[...]

 

[Vince C.]

Did you debug your service to see if you are even getting called, of if you
have a normal security issue (my bet, as all you are changing is the hosting
environment, and there is nothing i can remember from the top of my head
that should be different in our code in that respect).

The headers are send, the server figures request denied due to security,
soap never get's called. The described behaviour fits nicely with standard
security failures.

If I allow anonymous access to the web service everything runs normally.

Vince C.

 

[Vince C.]

Did you debug your service to see if you are even getting called, of if you
have a normal security issue (my bet, as all you are changing is the hosting
environment, and there is nothing i can remember from the top of my head
that should be different in our code in that respect).

The headers are send, the server figures request denied due to security,
soap never get's called. The described behaviour fits nicely with standard
security failures.

Frank

Frank,

If I manually set connector properties "AuthUser" and "AuthPassword"
connection is successful. If I don't use these properties, authentication
fails. It seems MS Soap client fails to correctly authenticate the current
logged on user.

If I put the same service as a subfolder of the default web, everything runs
as expected, whether authentication is enabled or not.

Can you tell me what's going wrong?

Thanks,
Vince C.