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

WinHttpWriteData and ERROR_WINHTTP_CONNECTION_ERROR (12030)

1,825 views
Skip to first unread message

HiChetu

unread,
Mar 15, 2004, 7:10:58 AM3/15/04
to
We are using WinHTTP 5.1. When we try to send data greater than 3MB
using WinHttpWriteData, it gives ERROR_WINHTTP_CONNECTION_ERROR.

For it to work with huge data, do we need to set any content-length?
Do we need to split up data manually into smaller chunks before
sending?.

Here is our code...

hSession = WinHttpOpen( L"HTTP Channel",
WINHTTP_ACCESS_TYPE_NO_PROXY,
WINHTTP_NO_PROXY_NAME,
WINHTTP_NO_PROXY_BYPASS, 0);
if (hSession)
hConnect = WinHttpConnect( hSession, bstrServer,
dwPort, 0);
PreAuthenticateHTTPChannel(hConnect, bstrPreferredServer, dwSecurity);

if (hConnect)
hRequest = WinHttpOpenRequest(hConnect, L"POST",
bstrPreferredServer,
NULL, WINHTTP_NO_REFERER,
WINHTTP_DEFAULT_ACCEPT_TYPES,

dwSecurity);

LPCWSTR szHeader = L"Content-Type: application/x-www-form-urlencoded";
.....

bResults = WinHttpSendRequest( hRequest, szHeader, wcslen(szHeader),0,
0,
lDataLen, 0);
if (bResults)
bResults = WinHttpWriteData(hRequest, pByte, lDataLen,

&dwBytesWritten);

//lDataLen = 12029306

if(!bResults)
hr = GetLastError();

//hr=12030, ERROR_WINHTTP_CONNECTION_ERROR

Please Help.
-- Chetan

Stephen Sulzer

unread,
Mar 15, 2004, 6:29:52 PM3/15/04
to

If you send less than 3MB of POST data, what is the response from the
server? Does it send back an authentication challenge (a 401 HTTP status
code) ? Or does it send back "200 OK"?

If your server requires authentication, can you confirm that the
PreAuthenticateHTTPChannel function is successfully authenticating with the
server? Also, do you know what kind of authentication the server uses
(Integrated Windows Authentication? Basic?)

If the pre-authentication request fails, and the server requires
authentication before it will accept your large POST request, the server may
abort the connection instead of waiting for your client to transmit all of
the POST data. I believe some servers, such as IIS (up to version 5.0), will
abort the connection before the client transmits all of a large POST
request. This would result in a WinHTTP connection error.

WinHTTP will set the Content-Type request header for you, based on the
dwTotalLength parameter of the WinHttpSendRequest API call.

You should first double check that the PreAuthenticateHTTPChannel function
is working. I wrote that function for someone on this newsgroup about 1
month ago. The function will send a HEAD request to the UrlPath (given by
your bstrPreferredServer string). If your bstrPreferredServer string
specifies an ASP/ASPX page, for example, the PreAuthenticate function may
fail because the server does not accept HEAD requests for an ASP/ASPX page.
So you may need to change the bstrPreferredServer parameter to
PreAuthenticateHTTPChannel to specify a static resource (e.g., something you
could send a GET request to), such as a dummy text file on the server.

Stephen


"HiChetu" <google...@gawab.com> wrote in message
news:d48e681e.04031...@posting.google.com...

HiChetu

unread,
Mar 16, 2004, 12:44:47 AM3/16/04
to
Hi Stephen,

Thank you for your response. Now for the questions you asked...

1) If we send less than 3MB of data we get back status code 200
2) PreAuthenticateHTTPChannel successfully authenticates the server.
3) 'bstrPreferredServer' was specifying a dummy text file as suggested
by you in one of your previous postings.
4) Data transfer failed both for Anonymous Authentication and
Integrated Windows Authentication

Thanks,
Chetan


"Stephen Sulzer" <sasulzer_at_seanet.com> wrote in message news:<105cf3l...@corp.supernews.com>...

Stephen Sulzer

unread,
Mar 16, 2004, 3:52:38 AM3/16/04
to
Ok. The next thing to do is to capture a trace of the HTTP request that
fails using the WinHttpTraceCfg.exe tool. The WinHTTP trace might show what
problem WinHttpWriteData is encountering. Look near the end of the trace
file for a "Winsock/RPC/SSL/Transport" error.

WinHttpTraceCfg is available with the Windows Server 2003 Resource Toolkit.
(You can use WinHttpTraceCfg.exe on Windows 2000 and XP as well as Server
2003.) The Resource Toolkit is available at:
http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

Documentation about the WinHttpTraceCfg tool can be found at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winhttp/http/winhttptracecfg_exe__a_trace_configuration_tool.asp


Another thing to consider is that a timeout may be occurring. Did you
override the send timeout using the WinHttpSetTimeouts API? The default send
timeout is 30000 (30 seconds). Try setting a very large send timeout value,
say 120000. How fast is the net connection between your client and server
machines?

You should consider implementing a workaround. For multi-megabyte POST
payloads, use separate WinHttpWriteData calls for each 1 megabyte (or less)
chunk of data.

Internally in WinHTTP 5.x, WinHttpWriteData will simply pass your data
buffer down to Winsock. Winsock should not have any trouble with a 3MB
buffer. For buffers larger than 4MB, WinHttpWriteData will pass the data to
Winsock in 4MB chunks (similar to the workaround I mentioned above).

Hope that helps.


Stephen


"HiChetu" <google...@gawab.com> wrote in message
news:d48e681e.04031...@posting.google.com...

HiChetu

unread,
Mar 16, 2004, 11:56:46 PM3/16/04
to
Hi Stephen,

Thanks for your suggestion. I used netmon to find about the network
traces. I found out that the webserver was returning an error
'Maximum.request.length.exceeded..---gt;.System.Web.HttpException:.Maximum.request.length.exceed."

On further investigation, I found out that the .NET default HTTP
maxRequestLength is 4096 KB. Because of which, we are not able to send
any attachments of size > 4MB. This maxRequestLength attribute is
present in machine.config file. We can override those values by
specifying those attributes in web.config file.

Other configurable attributes are as shown.
<!--
httpRuntime Attributes:
executionTimeout="[seconds]" - time in seconds
before request is automatically timed out
maxRequestLength="[KBytes]" - KBytes size of
maximum request length to accept
useFullyQualifiedRedirectUrl="[true|false]" - Fully qualify
the URL for client redirects
minFreeThreads="[count]" - minimum number
of free thread to allow execution of new requests
minLocalRequestFreeThreads="[count]" - minimum number of
free thread to allow execution of new local requests
appRequestQueueLimit="[count]" - maximum number of
requests queued for the application
enableKernelOutputCache="[true|false]" - enable the http.sys
cache on IIS6 and higher - default is true
enableVersionHeader="[true|false]" - outputs
X-AspNet-Version header with each request
-->


The default values are as shown :

<httpRuntime
executionTimeout="90"
maxRequestLength="4096"
useFullyQualifiedRedirectUrl="false"
minFreeThreads="8"
minLocalRequestFreeThreads="4"
appRequestQueueLimit="100"
enableVersionHeader="true"

/>


Thanks,
Chetan

"Stephen Sulzer" <sasulzer_at_seanet.com> wrote in message news:<105dg2v...@corp.supernews.com>...

Stephen Sulzer

unread,
Mar 17, 2004, 1:21:22 AM3/17/04
to
Glad to hear that the problem was diagnosed. I hadn't thought that the
server might be rejecting the request outright :^/ That's what tracing
tools are for.


0 new messages