WINHTTP_CALLBACK_STATUS_REQUEST_ERROR for unknown reason

[Dan]

Hello,

I wrote a small program that does a "POST" request
with some information to various sites.
I use winhttp 5.1 asynchronously and on one site I
received a "WINHTTP_CALLBACK_STATUS_REQUEST_ERROR"
status with
"ERROR_WINHTTP_INVALID_SERVER_RESPONSE". I used a
sniffer to find out the problem and I couldn't
find one! The strangest thing is that I wrote a
small server that sends the exact same reply and
it worked without a problem.
If anyone has any idea what's wrong here and why I
get good results when the same response is sent
from a different site I'll be greatful.

This is the log output I receive, sorry that it's
so long and I also changed the domain involved for
privacy reasons:

23:38:41.458 ::*Session* :: >>>> WinHttp Version
5.1 Build 5.1.2600 Aug 3 2004 22:24:11>>>>Process
Project1.exe [4828 (0x12dc)] started at
23:38:41.458 08/24/2006
23:38:48.268 ::*Session* :: WinHttpOpen("My
winhttp application", (1), "", "", 0x10000000)
23:38:48.278 ::*Session* :: WinHttpOpen()
returning handle 0xe25000
23:38:48.278 ::*Session* ::
WinHttpCrackUrl("http://www.somesite.com/page2.php",
0x0, 0x0, 0x12f1cc)
23:38:48.278 ::*Session* ::
WinHttpCrackUrlA("http://www.somesite.com/page2.php",
0x25, 0x0, 0x12f0e8)
23:38:48.278 ::*Session* :: WinHttpCrackUrlA()
returning TRUE
23:38:48.278 ::*Session* :: WinHttpCrackUrl()
returning TRUE
23:38:48.278 ::*Session* ::
WinHttpConnect(0xe25000, "www.somesite.com", 80,
0x0)
23:38:48.278 ::*Session* :: WinHttpConnect()
returning handle 0xe25100
23:38:48.278 ::*Session* ::
WinHttpOpenRequest(0xe25100, "POST", "/index.php",
"", "http://www.somesite.com/page1.php", 0x12f210,
0x00000000)
23:38:48.278 ::*Session* ::
WinHttpCreateUrlA(0x12ef70, 0x0, 0x20d0000,
0x12efac)
23:38:48.278 ::*Session* :: WinHttpCreateUrlA()
returning TRUE
23:38:48.278 ::*0000001* :: WinHttpOpenRequest()
returning handle 0x20f0000
23:38:48.278 ::*Session* ::
WinHttpSetStatusCallback(0x20f0000, 0x409a54,
0xffffffff)
23:38:48.278 ::*Session* ::
WinHttpSetStatusCallback() returning NULL
23:38:48.278 ::*0000001* ::
WinHttpSendRequest(0x20f0000, "Content-Type:
application/x-www-form-urlencoded\r\n", 49,
0xe375f4, 193, 193, e3604c)
23:38:48.278 ::*0000001* :: WinHttpSendRequest()
returning TRUE
23:38:48.288 ::*0000001* :: "www.somesite.com"
resolved
23:38:48.288 ::*0000001* :: sending data:
23:38:48.288 ::*0000001* :: 474 (0x1da) bytes
23:38:48.288 ::*0000001* :: <<<<-------- HTTP
stream follows
below ----------------------------------------------->>>>
23:38:48.288 ::*0000001* :: POST /nvform.php
HTTP/1.1
23:38:48.288 ::*0000001* :: Referer:
http://www.somesite.com/page1.php
23:38:48.288 ::*0000001* :: Accept: */*
23:38:48.288 ::*0000001* :: Content-Type:
application/x-www-form-urlencoded
23:38:48.288 ::*0000001* :: User-Agent:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1)
23:38:48.288 ::*0000001* :: Host: www.somesite.com
23:38:48.288 ::*0000001* :: Content-Length: 10
23:38:48.288 ::*0000001* :: Connection: Keep-Alive
23:38:48.288 ::*0000001* ::
23:38:48.288 ::*0000001* :: name=12345
23:38:48.288 ::*0000001* :: <<<<--------
End ----------------------------------------------->>>>
23:38:48.288 ::*0000001* ::
WinHttpReceiveResponse(0x20f0000, 0x0)
23:38:48.288 ::*0000001* ::
WinHttpReceiveResponse() returning TRUE
23:38:48.769 ::*0000001* :: received data:
23:38:48.769 ::*0000001* :: 270 (0x10e) bytes
23:38:48.769 ::*0000001* :: <<<<-------- HTTP
stream follows
below ----------------------------------------------->>>>
23:38:48.769 ::*0000001* :: HTTP/1.1 302 Found
23:38:48.769 ::*0000001* :: Date: Thu, 24 Aug 2006
20:40:03 GMT
23:38:48.769 ::*0000001* :: Server: Apache/1.3.34
(Unix) ConvertVP/2.1 PHP/4.4.0
23:38:48.769 ::*0000001* :: X-Powered-By:
PHP/4.4.0
23:38:48.769 ::*0000001* :: Location:
http://www.somesite.com/redirect.php
23:38:48.769 ::*0000001* :: Connection: close
23:38:48.769 ::*0000001* :: Transfer-Encoding:
chunked
23:38:48.769 ::*0000001* :: Content-Type:
text/html
23:38:48.769 ::*0000001* ::
23:38:48.769 ::*0000001* :: 0
23:38:48.769 ::*0000001* ::
23:38:48.769 ::*0000001* ::
23:38:48.769 ::*0000001* :: <<<<--------
End ----------------------------------------------->>>>
23:38:48.769 ::*0000001* ::
WINHTTP_CALLBACK_STATUS_REQUEST_ERROR: Failure API
= API_RECEIVE_RESPONSE, Error =
ERROR_HTTP_INVALID_SERVER_RESPONSE

Thank you
Dan

[jim kane]

straight from msdn one possible answer:
If the server HTTP response contains more that 64K of total header data,
WinHTTP fails the request with an ERROR_WINHTTP_INVALID_SERVER_RESPONSE
error.
Jijm Kane
"Dan" <no...@none.com> wrote in message
news:%235fpdf9...@TK2MSFTNGP04.phx.gbl...

[Dan]

Thank you for your reply. I've been away for a
long time and only now I saw your reply.
The possibility you describe here is not my case.
I investigated further and discovered that if I
removed the "Transfer-Encoding: chunked" from the
reply headers (on my own testing server)
everything works fine but when it's there the
error appears. Another strange issue is that if I
run my server on a port different than "80" or
"8080" it will still work WITH the
"Transfer-Encoding: chunked" header.

I checked other WinHTTP clients and not just mine
and it happens with all of them, it seems to me
like a bug but it's strange that I can't find any
documentation on the subject. It happened to me on
many different sites and it doesn't look that rare
to not be documented.

Another thing I want to add is that the response
trace looks like this:

02:25:46.677 ::*0000002* :: <<<<-------- HTTP
stream follows
below ----------------------------------------------->>>>
02:25:46.677 ::*0000002* :: HTTP/1.1 302 Found
02:25:46.677 ::*0000002* :: Server: IIS
02:25:46.677 ::*0000002* :: Location:
http://redirectsite.com
02:25:46.677 ::*0000002* :: Transfer-Encoding:
chunked
02:25:46.677 ::*0000002* :: Content-Type:
text/html
02:25:46.677 ::*0000002* ::
02:25:46.677 ::*0000002* :: 0
02:25:46.677 ::*0000002* ::
02:25:46.677 ::*0000002* :: 0
02:25:46.677 ::*0000002* ::
02:25:46.677 ::*0000002* ::
02:25:46.677 ::*0000002* :: <<<<--------
End ----------------------------------------------->>>>

Notice the extra "0" which appears on the trace.
It's not sent on the network (I've double
checked). The HTTP response ends like this on the
network:
Content-Type: text/html<CRLFCRLF>0<CRLFCRLF>

I'd appreciate any help you can give me right now

Thank you very much
Dan

[Dan]

Porblem solved. It appears that my antivirus
captures all traffic and scans it before
forwarding it to the various applications.
Well.... In this case it adds extra characters to
the reply and makes it unreadable. Very strange.
When it's down, however, it works perfectly.

Dan

[jim kane]

Interesting.
That is not the 1st time antivirus software has protected me against getting
my work done.
Jim Kane

"Dan" <no...@none.com> wrote in message

news:OObKR964...@TK2MSFTNGP06.phx.gbl...

[Aiya@discussions.microsoft.com Mithesh Aiya]

Well done Dan. But how did you guess that your antivirus is adding
unreadable characters? I am getting the same problem for the past two weeks
and it was working fine previously. The server that I am trying to contact
via WinHttpRequest.5.1 sometimes returns pdfs as MIME attachments. When pdfs
are received, I get this unrecognized response error and when there are no
MIME attachments, everything is ok. Could this be something to do with
certain Microsoft patches? I am sure it worked fine with PDFs for about 5
months and now suddenly this error comes up and is driving me crazy. My
WinHTTP trace looks similar to yours in the failure scenario.

I would appreciate your help on this.

Many Thanks
Mithesh Aiya