Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Error on WinHttpRequest

1,567 views
Skip to first unread message

Charlie B

unread,
Jul 17, 2002, 6:32:32 AM7/17/02
to
I am getting an intermittent error:

WinHttp.WinHttpRequest (0x8000000A)
The data necessary to complete this operation is not yet available.

Has anyone got an idea of what might cause this error ?

I am using VB6 and the Winhttp com object to post an XML document to a
tomcat webserver,
and expecting an XML document in the response. The component is inside a
Com+ application
that is called from IIS. The com+ activation is set to server.

Cheers

Charlie


Public Function fn_Test(strXML, strDTD_URI) as Boolean

Dim WinHttpReq As WinHTTP.WinHttpRequest
Dim s As Variant

On error goto errHandler

Set WinHttpReq = New WinHTTP.WinHttpRequest

s = strXML

WinHttpReq.Open "POST", strDTD_URI, False
WinHttpReq.SetRequestHeader "Content-type", "application/xml"

WinHttpReq.Send s
Exit Function
errHandler:
WriteErrorLog ""
End Function


Stephen Sulzer (Microsoft)

unread,
Jul 22, 2002, 2:25:46 AM7/22/02
to

This is likely a bug in WinHTTP. You should never get that particular error
code when using the component in synchronous mode.

How large is the POST payload that you are sending? And how large is the
typical response (XML document) that is received?

When the error occurs, do you know if the request (or part of it) has been
sent to the webserver?

One thing to try would be to set infinite timeouts for the DNS name
resolving, connecting, sending and receiving operations:

WinHttpReq.Open "POST", strDTD_URI, False

WinHttpReq.SetTimeouts 0, 0, 0, 0 ' 0 or -1 means infinite

WinHttpReq.SetRequestHeader "Content-type", "application/xml"

WinHttpReq.Send s


(The default timeouts for DNS name resolving, connecting, sending and
receiving are: infinite, 60 seconds, 30 seconds, and 30 seconds,
respectively.)

If doing that seems to "fix" the problem, then try to narrow the scenario
down a bit further by specifying infinite timeouts for all but one of the
operations (except DNS resolution). For example, specify a 30 second connect
timeout, and 0 (infinite) for the other three parameters.


Regards,

Stephen Sulzer
Microsoft Corporation


This posting is provided "AS IS" with no warranties, and confers no rights.

"Charlie B" <Pork...@neil.servebeer.com> wrote in message
news:OTnku0XLCHA.1236@tkmsftngp08...

Charlie B

unread,
Jul 24, 2002, 6:21:59 AM7/24/02
to
Stephen,

The post is between 5,300 and 5,500 bytes in size.

The response is around 2000 bytes or less.

Looking at the tomcat logs I can see that all of the request has been
recieved, however, the response is not generated until 46 seconds after the
request is recieved.

I will try your infinite timeouts suggestion, it will take some time to test
as it is quite rare that I recieve this error.

Cheers,

Charlie

Stephen Sulzer (Microsoft)" <ssu...@online.microsoft.com> wrote in message
news:e#Gb#hUMCHA.2748@tkmsftngp13...

Stephen Sulzer (Microsoft)

unread,
Jul 24, 2002, 6:14:51 PM7/24/02
to
The 46 second response time exceeds WinHTTP's default 30 second receive
timeout. However, in that case I would expect a timeout error, and not the
"data is still pending" error you are getting.

In addition to trying infinite timeout settings, I would also examine the
server's HTTP response using NETMON or WinHTTP's trace facility, and double
check that Content-Length value is correct. If the Content-Length response
header is larger than the actual size of the response body, (and if
keep-alive is enabled), that would cause connection problems for WinHTTP.
With keep-alive enabled, an HTTP client must rely on the server to specify
an accurate Content-Length value.


Regards,

Stephen Sulzer
Microsoft Corporation


This posting is provided "AS IS" with no warranties, and confers no rights.

"Charlie B" <Pork...@neil.servebeer.com> wrote in message

news:#jqHTvvMCHA.2096@tkmsftngp12...

Charlie B

unread,
Jul 25, 2002, 6:27:44 AM7/25/02
to
Stephen,

Thanks for the info, i'll try using the WinHTTP trace utillity.

Cheers

Charlie

"Stephen Sulzer (Microsoft)" <ssu...@online.microsoft.com> wrote in message

news:#pcb091MCHA.1624@tkmsftngp10...

0 new messages