HTTP protocol question related to Web Service under IIS 5 (long)

[DT]

I'm writing a .NET 1.1 client that invokes a method of a Web Service running
on another organization's IIS 5 server. I need help understanding a fine
point about HTTP, specifically in relation to the use of the Expect:
100-Continue header, in order to determine whether the problem is with my
client or their server.

Here's the situation:

After invoking the web service successfully one time, all subsequent
requests then fail. Using IE, I can still retrieve the WSDL from their
server (eg, http://their-server/app-path?wsdl) , and can still get their
server to return the formatted service description page (eg,
http://their-server/app-path), so I know that their IIS is still "up" (at
least partly).

So I used NetMon to capture the traffic of a failed request. I can see that
my "client"* first sends the HTTP POST along with its various headers,
including Expect: 100-Continue.

* (actually, the .NET runtime sends the POST on behalf of my "client" ... my
code is simply invoking the web service method)

But their server doesn't return any status code, either 100-Continue or 417
(Expectation failed).

But then my client then proceeds to send the message body containing the
SOAP-encoded invocation of the method, even though it never got a status
code from the server. And their server then returns an application-level
error from their web service.

My basic question: is it OK for my client to go ahead and send the message
body even though it hasn't received the 100-Continue status?

According to RFC 2616:

"8.2.3 Use of the 100 (Continue) Status - Because of the presence of older
implementations , ... a client may send "Expect: 100-continue" without
receiving either a 417 or 100 status. ...the client SHOULD NOT wait for an
indefinate period before sending the request body.".

If I'm reading this correctly, it sounds like my .NET client is allowed to
send the request body if it doesn't receive the expected 100-continue
status.

Correct?

Thanks,

DT