iislog sc-win32-status = 64 and sc-status = 200

[unknown]

Can anyone articulate an explanation why an iislog record would contain a
sc-win32-status = 64 (type net helpmsg 64 at cmd prompt gets "The specified
network name is no longer available") but the sc-status code is 200
("Successful")?

Thanks.

[David Wang]

Post by unknown
Can anyone articulate an explanation why an iislog record would contain a
sc-win32-status = 64 (type net helpmsg 64 at cmd prompt gets "The specified
network name is no longer available") but the sc-status code is 200
("Successful")?
Thanks.

Because sc-status code represents what IIS sent for the HTTP response,
and sc-win32-status can represent the network's result when
transporting that response.

The two are clearly not related. Just because ASP page executed
successfully to generate a 200 response does NOT mean the client sees
the response -- the network between server and client is not reliable.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[David Wang]

Hi David,
Thanks for your meaningful answer.
Could you respond, how can I found the source of sc-win32-status=64 in my network? What could be a reason of non-reliable connection between server and client, anything?
Thank you in advance,
Andrei
SE
EggHeadCafe.com - .NET Developer Portal of Choicehttp://www.eggheadcafe.com

The ASP page may take 10 seconds to generate a response (suppose it is
querying a large SQL table on the back-end), and the user may have hit
a F5 to refresh after waiting for 10 seconds. The client abandoned the
connection to cause Win32 error 64 while IIS was just sending the
ASP's successful response.

Unless you are seeing lots of them, there may be nothing you can do
about it. You probably cannot prevent the user from hitting F5 to
refresh.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[a***@gmail.com]

Post by David Wang
Unless you are seeing lots of them, there may be nothing you can do
about it. You probably cannot prevent the user from hitting F5 to
refresh.

Yes, you right, this sounds reasonable. But actually I have the
following situation.

My APP is ASP application on IIS 6.0 in cluster of 8 servers
(WinServer 2003). Clients can download different documents: PDF, HTML,
txt, etc... Requests from one client could be passed either one by
one, e.g. by clicking on link on website, or in batch mode (but not
simultaneously, I guess) called from some sort of scripts.

So I've been testing my app with my own script located outside of
cluster and got the following results:
- 20 requests for different PDF documents were passed in cycle one by
one (GET request):
3 of them had sc-status=200, sc-win32-status=64, sc-bytes=0;
7 - sc-status=200, sc-win32-status=64, sc-bytes>0;
other were good.
ALL PDFs were successfully downloaded and correct!
- 5 requests for some xml data (not xml files) were passed in cycle
one by one (POST request):
first 4 were good;
last one has sc-status=200, sc-win32-status=64, sc-bytes=0. Actually
this is reproducible for any number of requests, even for 1!

All those requests were passed through HTTP 1.1 with
MSXML2.ServerXMLHTTP object. If HTTPS was used:
- ALL xml data requests were passed successfully;
- there were no sc-status=200, sc-win32-status=64, sc-bytes>0 entries
in IIS logs;
- sometimes there were sc-status=200, sc-win32-status=64, sc-bytes=0
entries - in this case "The server returned an invalid or unrecognized
response" error was returned by MSXML2.ServerXMLHTTP.
ONLY PDFs without "The server returned an invalid or unrecognized
response" error were successfully downloaded.

So I didn't interrupt any of requests while their executing but sc-
win32-status=64 anyway was in my logs. HTTP - HTTPS different behavior
looks interesting as well.

David, could you say something about such system behavior, in which
way should I look to find out the solution of this issue? Any
suggestions are really appreciated.

Thanks a lot,
Andrei

[David Wang]

Post by a***@gmail.com

Post by David Wang
Unless you are seeing lots of them, there may be nothing you can do
about it. You probably cannot prevent the user from hitting F5 to
refresh.

Yes, you right, this sounds reasonable. But actually I have the
following situation.
My APP is ASP application on IIS 6.0 in cluster of 8 servers
(WinServer 2003). Clients can download different documents: PDF, HTML,
txt, etc... Requests from one client could be passed either one by
one, e.g. by clicking on link on website, or in batch mode (but not
simultaneously, I guess) called from some sort of scripts.
So I've been testing my app with my own script located outside of
- 20 requests for different PDF documents were passed in cycle one by
3 of them had sc-status=200, sc-win32-status=64, sc-bytes=0;
7 - sc-status=200, sc-win32-status=64, sc-bytes>0;
other were good.
ALL PDFs were successfully downloaded and correct!
- 5 requests for some xml data (not xml files) were passed in cycle
first 4 were good;
last one has sc-status=200, sc-win32-status=64, sc-bytes=0. Actually
this is reproducible for any number of requests, even for 1!
All those requests were passed through HTTP 1.1 with
- ALL xml data requests were passed successfully;
- there were no sc-status=200, sc-win32-status=64, sc-bytes>0 entries
in IIS logs;
- sometimes there were sc-status=200, sc-win32-status=64, sc-bytes=0
entries - in this case "The server returned an invalid or unrecognized
response" error was returned by MSXML2.ServerXMLHTTP.
ONLY PDFs without "The server returned an invalid or unrecognized
response" error were successfully downloaded.
So I didn't interrupt any of requests while their executing but sc-
win32-status=64 anyway was in my logs. HTTP - HTTPS different behavior
looks interesting as well.
David, could you say something about such system behavior, in which
way should I look to find out the solution of this issue? Any
suggestions are really appreciated.
Thanks a lot,
Andrei

Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

So, I am not terribly fascinated by the actual numbers in your log
file; I am more concerned that your server-side applications are not
able to consistently send back proper responses to be interpreted by
the client.

Do you only see the errors with your scripts or do you see them with
real people using browsers (i.e. is the issue something to do with
your network configuration or server-side application, which would be
"consistently but randomly" affecting scripts and browsers, or is it
specific to how your scripts work).

Also, "downloading" is not all the same. PDF retrieval by a browser
can be different, and resources can be retrieved/sent in different
ways as well, even though it is all "downloading".

Finally, if your resources are not sent by IIS (i.e. your XML data are
not files sent by IIS but rather data sent by custom server-side
application code), that code can be suspect. For example, does the
code send a proper HTTP response, where content-length/type matches up
byte-for-byte? If the code is even off by one, then it could cause the
server or client to misunderstand each other and cause issues like you
observe.

I recommend that you review both how your client script and server-
side application works to send data because it may be causing the
different results on its own.

And if you observe the issue with both scripts and real browser
clients, then the culprit may be some commonly shared networking
device.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[a***@gmail.com]

Hi David,

Awesome thanks for your help. I got your thoughts and will check both
my server-side and client scripts.

Actually I'm not sure that clients have troubles with their browsers
as soon as I see _all_ GET requests have cs(User-Agent) - Mozilla/4.0+
(compatible;+Win32;+WinHttp.WinHttpRequest.5) .
POST requests for raw XML data don't contain any data about clients
user agents.

As I understand "Mozilla/4.0+(compatible;
+Win32;+WinHttp.WinHttpRequest.5)" means that this request was
performed with WinHttpRequest or ServerXMLHTTP/XMLHTTP object - I
believe this was done from client script-like application.

So as said above will check my applications. If you have anything to
add please respond.

Will back with investigation results.

Best Regards,
Andrei

[a***@gmail.com]

Post by a***@gmail.com
Will back with investigation results.

Hi,

The first thing I've found is there are 2 "Content-Length" headers in
response from my APP, e.g.:

CONTENT-LENGTH: 275444
Content-Length: 275445

First one is added by my APP. When I've disabled it at almost all "200
0 64" errors are gone away except the last request in the batch. But I
believe it is because of another reason.

Continue my investigation. Colleagues if you have something to add,
please respond.

Thank you,
Andrei

[a***@gmail.com]

Hi,

Actually now _all_ GET document requests are OK without "200 0 64"
entries in IIS logs. _David, thanks a lot_

The last thing is that issue still exists for POST requests for raw
xml data. If I'm posting one by one set of requests in loop the last
one always marked with "200 0 64" in IIS logs. ..investigating..

--Andrei

[David Wang]

You're welcome.

In your case with duplicate Content-Length headers, the behavior is
unspecified. If the client chose to obey the first (smaller) value, it
would stop reading one less byte than the server sent -- so the server
thinks the client closed the connection without reading that last byte
(Win32=64) while the client was misled by the duplicate Content-Length
headers and thinks it read everything.

For POST requests, make sure the content-length on the request and
response match up. If only the final response returns Win32=64, it
suggests that something is consistently off-by-one with the server-
side application, but the cumulative result would not be obvious to
the client/server until the very last request/response of the stream
of requests.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Post by a***@gmail.com
Hi,
Actually now _all_ GET document requests are OK without "200 0 64"
entries in IIS logs. _David, thanks a lot_
The last thing is that issue still exists for POST requests for raw
xml data. If I'm posting one by one set of requests in loop the last
one always marked with "200 0 64" in IIS logs. ..investigating..
--Andrei

[a***@gmail.com]

Post by David Wang
For POST requests, make sure the content-length on the request and
response match up. If only the final response returns Win32=64, it
suggests that something is consistently off-by-one with the server-
side application, but the cumulative result would not be obvious to
the client/server until the very last request/response of the stream
of requests.

Yes, I checked this out, but content-length looks to be correct now in
both request and response. ...double checking...

David, actually do you remeber I wrote that raw xml data requests are
OK with _HTTPS_, rather than we have the above errors for simple
_HTTP_. How could this be?

Thank you,
Andrei

[a***@gmail.com]

Last update.

Unfortunatelly can't reproduce "200 0 64" with Fiddler.

Thanks,
Andrei

[a***@gmail.com]

Hi,

Even simple code run like the following gives me "200 0 64" in my IIS
logs:

var sUrl = "http://[host]/[target].asp";

var xmlHttp = new ActiveXObject("Msxml2.ServerXMLHTTP");
xmlHttp.open("POST", sUrl, false);
xmlHttp.send();

xmlHttp = null;


Corresponding HTTP POST stream looks like the following:

POST [target].asp HTTP/1.1
Accept-Language: en-us
Content-Length: 0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: [host name]
Connection: Keep-Alive

The HTTP response stream is:

HTTP/1.1 200 OK
Date: Wed, 11 Apr 2007 15:22:16 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
machine: [machine name]
P3P: CP="NOI CAO DSP COR DEV ADM TAI PSA OUR STP NAV COM STA"
Set-Cookie: [app cookie];path=/;
Content-Length: 527
Content-Type: text/xml
Expires: Wed, 11 Apr 2007 15:21:16 GMT
Cache-control: private

<?xml version="1.0" encoding="UTF-8"?>
[standard app xml response]

Could you suggest why is it so?

Many thanks,
Andrei

[David Wang]

If it works over HTTPS but fails over HTTP, then there is still
something wrong with your request/response. Just because it seems to
work with HTTPS does not mean it is actually correct.

You need to provide:
1. Where the \r\n (CRLF) line terminators are
2. Server-side treatment of Connection KeepAlive -- client requests
it, server response allows it, but what does server-side application
do?
3. Client side code reading response and treatment of connection


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Post by a***@gmail.com
Hi,
Even simple code run like the following gives me "200 0 64" in my IIS
var sUrl = "http://[host]/[target].asp";
var xmlHttp = new ActiveXObject("Msxml2.ServerXMLHTTP");
xmlHttp.open("POST", sUrl, false);
xmlHttp.send();
xmlHttp = null;
POST [target].asp HTTP/1.1
Accept-Language: en-us
Content-Length: 0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: [host name]
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Wed, 11 Apr 2007 15:22:16 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
machine: [machine name]
P3P: CP="NOI CAO DSP COR DEV ADM TAI PSA OUR STP NAV COM STA"
Set-Cookie: [app cookie];path=/;
Content-Length: 527
Content-Type: text/xml
Expires: Wed, 11 Apr 2007 15:21:16 GMT
Cache-control: private
<?xml version="1.0" encoding="UTF-8"?>
[standard app xml response]
Could you suggest why is it so?
Many thanks,
Andrei

[a***@gmail.com]

Hi David, again many thanks for your attention to my problem.

Below is the testing client and server side code I'm currently using.
It's similar to production one, I mean it uses the same logic and
methods.
Hope this helps to clarify my issue.

Client side code (s-run.js):
====================================
var sUrl = "http://[host name]/test.asp";

var xmlHttp = new ActiveXObject("Msxml2.ServerXMLHTTP");

xmlHttp.open("POST", sUrl, false);
xmlHttp.send();

xmlHttp = null;
====================================

Server side code (test.asp):
====================================
<%@ Language=VBScript %><%option explicit%>
<%
' script timeout
Server.ScriptTimeout = 10 * 60 ' seconds

' always return XML
Response.ContentType = "text/xml"

' turn off caching
Response.Expires = -1

' all done
call MyResponseEnd("Test Message")


sub MyResponseEnd(byref ErrorMessage)
dim oXMLDOMRequest

set oXMLDOMRequest = Server.CreateObject("MSXML2.DOMDocument.4.0")
if (not oXMLDOMRequest.load(Request)) then
ErrorMessage = ErrorMessage + " - error: " & _
oXMLDOMRequest.parseError
else
ErrorMessage = ErrorMessage + " - success"
end if

set oXMLDOMRequest = nothing


dim oXMLDOMResponse
dim oRootNode, oSimpleResponseNode

' create new XML response skeleton
set oXMLDOMResponse = _
Server.CreateObject("MSXML2.DOMDocument.4.0")

' add XML processing instruction
call oXMLDOMResponse.appendChild( _
oXMLDOMResponse.createProcessingInstruction( _
"xml", "version=""1.0"" encoding=""UTF-8"""))

' determine "root"
set oRootNode = oXMLDOMResponse

set oSimpleResponseNode = _
oRootNode.appendChild( _
oXMLDOMResponse.createNode( _
1, _
"SimpleResponse", _
""))

' add attributes to "SimpleResponse" element
call oSimpleResponseNode.setAttribute("ErrorMessage", ErrorMessage)

' respond with XML
call Response.Clear()
call oXMLDOMResponse.save(Response)

' destroy global objects
set oXMLDOMResponse = nothing

' exit page
call Response.End()
end sub ' MyResponseEnd
%>
====================================

Thank you,
Andrei

Post by David Wang
If it works over HTTPS but fails over HTTP, then there is still
something wrong with your request/response. Just because it seems to
work with HTTPS does not mean it is actually correct.
1. Where the \r\n (CRLF) line terminators are
2. Server-side treatment of Connection KeepAlive -- client requests
it, server response allows it, but what does server-side application
do?
3. Client side code reading response and treatment of connection
//Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
//

Post by a***@gmail.com
Hi,
Even simple code run like the following gives me "200 0 64" in my IIS
var sUrl = "http://[host]/[target].asp";
var xmlHttp = new ActiveXObject("Msxml2.ServerXMLHTTP");
xmlHttp.open("POST", sUrl, false);
xmlHttp.send();
xmlHttp = null;
POST [target].asp HTTP/1.1
Accept-Language: en-us
Content-Length: 0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: [host name]
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Wed, 11 Apr 2007 15:22:16 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
machine: [machine name]
P3P: CP="NOI CAO DSP COR DEV ADM TAI PSA OUR STP NAV COM STA"
Set-Cookie: [app cookie];path=/;
Content-Length: 527
Content-Type: text/xml
Expires: Wed, 11 Apr 2007 15:21:16 GMT
Cache-control: private
<?xml version="1.0" encoding="UTF-8"?>
[standard app xml response]
Could you suggest why is it so?
Many thanks,
Andrei- Hide quoted text -

- Show quoted text -

[a***@gmail.com]

as addition:

I even ran the above client side code against the following server one
but again got "200 0 64" in my IIS log.

<%
Response.Write "test is ok"
%>

[a***@gmail.com]

as addition:

I even ran the above client side code against the following server one
but again got "200 0 64" in my IIS log.

<%
Response.Write "test is ok"
%>

p.s. but you know it's ok with Fiddler.

[David Wang]

Post by a***@gmail.com
I even ran the above client side code against the following server one
but again got "200 0 64" in my IIS log.
<%
Response.Write "test is ok"
%>
p.s. but you know it's ok with Fiddler.

Can you provide what is actually sent over the wire with your custom
code?

And please be weary that the code you are using to debug is actually
representative of your actual code, or else we may end up looking at
things that have no effect on your actual application.

Is there any proxy server or network device between your client and
server that could be behaving differently for POST requests. For
example, connection-pooling, which would be possible for HTTP requests
but not HTTPS.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[a***@gmail.com]

I don't know about any proxy or network devices which could affect
requests. But sure I'll request this information from our ops. Thanks.

Post by David Wang
And please be weary that the code you are using to debug is actually
representative of your actual code, or else we may end up looking at
things that have no effect on your actual application.

Yes sure I'm running my scripts against actual code as well.

Post by David Wang
Can you provide what is actually sent over the wire with your custom
code?

I checked server with Ethereal sniffer and got the following results.

1. In case if I make a call from my script through
MSXML2.ServerXMLHTTP object there is the following requests/responses
order:
...
- server sends http response "HTTP/1.1 200 OK" to the client;
- reset connection request "19445 > http [RST, ACK] Seq=245
Ack=3947741440 Win 0 Len 0" is received from the client.

2. In case if I make a call with wfetch tool with unchecked socket
reuse:
...
- server sends http response "HTTP/1.1 200 OK" to the client;
- acknowledge response "36800 > http [ACK] Seq=280 Ack=1158891301 Win
65266 Len 0" is received from the client;
- reset connection request "36800 > http [RST, ACK] Seq=280
Ack=1158891301 Win 0 Len 0" is received from the client.

The 1-st request has sc-win32-status=64 in IIS logs, 2-nd one is OK.
Raw HTTP requests and responses are the same in both cases except one
thing - in 1-st request it doesn't contain host name, I mean it looks
like /[app dir]/test.asp. In 2-nd request it is looks like http://[host
name]/[app dir]/test.asp.

Thanks.
Andrei

[a***@gmail.com]

Hope above helps to help me :)

Thank you,
Andrei

[a***@gmail.com]

Colleagues, any ideas?

Thank you in advance,
Andrei

[Noemi]

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.

Here's the scenario:

a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.

Can you shed some light why does this happen?

Thanks!

[Larry]

Hi,

I am having a "similar" situation. Let me explain why I "" quoted the word
similar.

I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.

I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.

I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.

An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.

When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.

Here's the problem -

If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.

When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0

With IE7 always 2 requests - with IE6 always 1 request.

So, as I mentioned, same IIS log entry but how the entries are generated is
different.

I have researched what might be causing this and so far - nothing definite.

Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.

Any further discussion and/or help would be greatly appreciated.

Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!

[David Wang]

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
for duplicate requests to be generated, such as:
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[Larry]

Thank you for your response David. I am researching your suggestions.

In doing so, I'd like for you to reference a posting -

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=6a92c456-a435-4c52-b58b-6534a5db1563&dg=microsoft.public.internetexplorer.general

This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.

Any comment would be appreciated.

Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[David Wang]

Post by Larry
Thank you for your response David. I am researching your suggestions.
In doing so, I'd like for you to reference a posting -
http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...
This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.
Any comment would be appreciated.
Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

Hmm, sounds like an IE7 issue. It seems like the only way you can deal
with it is to session your POSTs so that you avoid duplicates.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[Larry]

Thanks David.

Do you feel this is an issue where calling Microsoft support is in order?

If a report was made during beta, and the issue still exists, programming
around it is really not the solution - isit?

I realize we can probably program to avoid temporarily but we have potential
for over 1000 apps to have this problem with over 3000 users.

Yours thoughts are greatly appreciated - along with any other folks watching
in.
--
Larry

Post by David Wang

Post by Larry
Thank you for your response David. I am researching your suggestions.
In doing so, I'd like for you to reference a posting -
http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...
This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.
Any comment would be appreciated.
Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

Hmm, sounds like an IE7 issue. It seems like the only way you can deal
with it is to session your POSTs so that you avoid duplicates.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[Larry]

Would like to add some new comments here -

We believe we have found the culprit to this duplicate issue. It deals with
the way <input buttons are used. This may be a documented thing - but we
surely did not catch this. Here is an email from a developer working on this
case with me.
-----------
We have potentially solve the issue, we changed our form from <input
type="submit" to <input type="button" and had Sharon K. run an E-mail Quote
on TEST. This resulted in a single email sent. I then switched it back to
<input type="submit" and had her do this again, which resulted in duplicate
emails.

It seems the change to type="button" has temporarily solved the issue.
----------

Is this something that is documented - I'm going to find out. We were not
aware of it between IE6 and IE7. Maybe IE6 was more forgiving and IE7 isn't -
just not sure - YET.

Also I would like to point out that I tried this email app on Netscape v8
and got duplicates - change the button - got single. So this is not an IE7
thing. More browsers to test.

Wanted to make these comments to everyone who may have read this.

Thanks David for your comments.
--
Larry

Post by Larry
Thanks David.
Do you feel this is an issue where calling Microsoft support is in order?
If a report was made during beta, and the issue still exists, programming
around it is really not the solution - isit?
I realize we can probably program to avoid temporarily but we have potential
for over 1000 apps to have this problem with over 3000 users.
Yours thoughts are greatly appreciated - along with any other folks watching
in.
--
Larry

Post by David Wang

Post by Larry
Thank you for your response David. I am researching your suggestions.
In doing so, I'd like for you to reference a posting -
http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...
This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.
Any comment would be appreciated.
Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

Hmm, sounds like an IE7 issue. It seems like the only way you can deal
with it is to session your POSTs so that you avoid duplicates.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[Larry]

I want to add some final comments on this issue -

We have found the culprit to our duplicate request problem -

The code within the form that defined the submit button and handled the
reqeust to the app that sent an email was:
-------
<td align="right" width="50%">
<input class="btnNorm" type="submit" id="btnSend" value="Send" style="WIDTH:
72px; HEIGHT: 24px"
onclick="javascript:ShowProcessingMessage();
document.getElementById('Form1').submit();">
</td>
--------

Using IE6 this form submit sent a single request to the application - thus a
single email sent.

If you use IE7, everything else the same, the submit sent 2 requests to the
application - thus duplicate emails.

Changing the code on the button to:
-------------
<td align="right" width="50%">
<input class="btnNorm" type="submit" id="btnSend" value="Send" style="WIDTH:
72px; HEIGHT: 24px">
</td>
-----------

IE6 sends a single AND IE7 sends a single.

Our developers should have caught this difference when they tested IE7 - but
they didn't. Suffice it to say - there is definitly a difference between IE6
and IE7.

Also, using Netscaler, the button configured 1 way sent 2, the other way
sent 1. Other brwosers yet to test.

Thanks.
--
Larry

Post by Larry
Would like to add some new comments here -
We believe we have found the culprit to this duplicate issue. It deals with
the way <input buttons are used. This may be a documented thing - but we
surely did not catch this. Here is an email from a developer working on this
case with me.
-----------
We have potentially solve the issue, we changed our form from <input
type="submit" to <input type="button" and had Sharon K. run an E-mail Quote
on TEST. This resulted in a single email sent. I then switched it back to
<input type="submit" and had her do this again, which resulted in duplicate
emails.
It seems the change to type="button" has temporarily solved the issue.
----------
Is this something that is documented - I'm going to find out. We were not
aware of it between IE6 and IE7. Maybe IE6 was more forgiving and IE7 isn't -
just not sure - YET.
Also I would like to point out that I tried this email app on Netscape v8
and got duplicates - change the button - got single. So this is not an IE7
thing. More browsers to test.
Wanted to make these comments to everyone who may have read this.
Thanks David for your comments.
--
Larry

Post by Larry
Thanks David.
Do you feel this is an issue where calling Microsoft support is in order?
If a report was made during beta, and the issue still exists, programming
around it is really not the solution - isit?
I realize we can probably program to avoid temporarily but we have potential
for over 1000 apps to have this problem with over 3000 users.
Yours thoughts are greatly appreciated - along with any other folks watching
in.
--
Larry

Post by David Wang

Post by Larry
Thank you for your response David. I am researching your suggestions.
In doing so, I'd like for you to reference a posting -
http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...
This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.
Any comment would be appreciated.
Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

Hmm, sounds like an IE7 issue. It seems like the only way you can deal
with it is to session your POSTs so that you avoid duplicates.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[David Wang]

Glad you found the culprit. My gut feeling is that the issue is with
the code that you removed and not a bug in IE7 and other browsers.

I'm not a Web Developer, but I went looking for the meaning
of .submit() and found this:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357

It indicates that calling .submit() is analogous to clicking the
submit button.

So, when the user clicks the <input> button with your existing code
of:

<td align="right" width="50%">
<input class="btnNorm" type="submit" id="btnSend" value="Send"
style="WIDTH:72px; HEIGHT: 24px"
onclick="javascript:ShowProcessingMessage();document.getElementById('Form1').submit();">
</td>


The browser probably:
1. Calls ShowProcessingMessage()
2. Trigger the Submit button -- which is this input button itself, so
it again:
- Calls ShowProcessingMessage()
- Trigger the Submit button -- which is this input button itself,
so it again:
- Probably when the browser noticed the infinite loop and
stopped it, but not before two ShowProcessingMessage() (hence two
POSTs) has been invoked.


In my mind, ShowProcessingMessage() should have code to prevent itself
from being called multiple times since CSS/DOM can definitely cause it
to be called multiple times.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Post by Larry
I want to add some final comments on this issue -
We have found the culprit to our duplicate request problem -
The code within the form that defined the submit button and handled the
-------
<td align="right" width="50%">
72px; HEIGHT: 24px"
onclick="javascript:ShowProcessingMessage();
document.getElementById('Form1').submit();">
</td>
--------
Using IE6 this form submit sent a single request to the application - thus a
single email sent.
If you use IE7, everything else the same, the submit sent 2 requests to the
application - thus duplicate emails.
-------------
<td align="right" width="50%">
72px; HEIGHT: 24px">
</td>
-----------
IE6 sends a single AND IE7 sends a single.
Our developers should have caught this difference when they tested IE7 - but
they didn't. Suffice it to say - there is definitly a difference between IE6
and IE7.
Also, using Netscaler, the button configured 1 way sent 2, the other way
sent 1. Other brwosers yet to test.
Thanks.
--
Larry

Post by Larry
Would like to add some new comments here -
We believe we have found the culprit to this duplicate issue. It deals with
the way <input buttons are used. This may be a documented thing - but we
surely did not catch this. Here is an email from a developer working on this
case with me.
-----------
We have potentially solve the issue, we changed our form from <input
type="submit" to <input type="button" and had Sharon K. run an E-mail Quote
on TEST. This resulted in a single email sent. I then switched it back to
<input type="submit" and had her do this again, which resulted in duplicate
emails.
It seems the change to type="button" has temporarily solved the issue.
----------
Is this something that is documented - I'm going to find out. We were not
aware of it between IE6 and IE7. Maybe IE6 was more forgiving and IE7 isn't -
just not sure - YET.
Also I would like to point out that I tried this email app on Netscape v8
and got duplicates - change the button - got single. So this is not an IE7
thing. More browsers to test.
Wanted to make these comments to everyone who may have read this.
Thanks David for your comments.
--
Larry

Post by Larry
Thanks David.
Do you feel this is an issue where calling Microsoft support is in order?
If a report was made during beta, and the issue still exists, programming
around it is really not the solution - isit?
I realize we can probably program to avoid temporarily but we have potential
for over 1000 apps to have this problem with over 3000 users.
Yours thoughts are greatly appreciated - along with any other folks watching
in.
--
Larry

Post by David Wang

Post by Larry
Thank you for your response David. I am researching your suggestions.
In doing so, I'd like for you to reference a posting -
http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...
This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.
Any comment would be appreciated.
Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

Hmm, sounds like an IE7 issue. It seems like the only way you can deal
with it is to session your POSTs so that you avoid duplicates.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

[Larry]

The definition of the button uses the onClick event - which should only occur
once - right? Why would this generate a loop condition? I think I might be
missing your point David.

Thanks
--
Larry

Post by David Wang
Glad you found the culprit. My gut feeling is that the issue is with
the code that you removed and not a bug in IE7 and other browsers.
I'm not a Web Developer, but I went looking for the meaning
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357
It indicates that calling .submit() is analogous to clicking the
submit button.
So, when the user clicks the <input> button with your existing code
<td align="right" width="50%">
<input class="btnNorm" type="submit" id="btnSend" value="Send"
style="WIDTH:72px; HEIGHT: 24px"
onclick="javascript:ShowProcessingMessage();document.getElementById('Form1').submit();">
</td>
1. Calls ShowProcessingMessage()
2. Trigger the Submit button -- which is this input button itself, so
- Calls ShowProcessingMessage()
- Trigger the Submit button -- which is this input button itself,
- Probably when the browser noticed the infinite loop and
stopped it, but not before two ShowProcessingMessage() (hence two
POSTs) has been invoked.
In my mind, ShowProcessingMessage() should have code to prevent itself
from being called multiple times since CSS/DOM can definitely cause it
to be called multiple times.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Post by Larry
I want to add some final comments on this issue -
We have found the culprit to our duplicate request problem -
The code within the form that defined the submit button and handled the
-------
<td align="right" width="50%">
72px; HEIGHT: 24px"
onclick="javascript:ShowProcessingMessage();
document.getElementById('Form1').submit();">
</td>
--------
Using IE6 this form submit sent a single request to the application - thus a
single email sent.
If you use IE7, everything else the same, the submit sent 2 requests to the
application - thus duplicate emails.
-------------
<td align="right" width="50%">
72px; HEIGHT: 24px">
</td>
-----------
IE6 sends a single AND IE7 sends a single.
Our developers should have caught this difference when they tested IE7 - but
they didn't. Suffice it to say - there is definitly a difference between IE6
and IE7.
Also, using Netscaler, the button configured 1 way sent 2, the other way
sent 1. Other brwosers yet to test.
Thanks.
--
Larry

Post by Larry
Would like to add some new comments here -
We believe we have found the culprit to this duplicate issue. It deals with
the way <input buttons are used. This may be a documented thing - but we
surely did not catch this. Here is an email from a developer working on this
case with me.
-----------
We have potentially solve the issue, we changed our form from <input
type="submit" to <input type="button" and had Sharon K. run an E-mail Quote
on TEST. This resulted in a single email sent. I then switched it back to
<input type="submit" and had her do this again, which resulted in duplicate
emails.
It seems the change to type="button" has temporarily solved the issue.
----------
Is this something that is documented - I'm going to find out. We were not
aware of it between IE6 and IE7. Maybe IE6 was more forgiving and IE7 isn't -
just not sure - YET.
Also I would like to point out that I tried this email app on Netscape v8
and got duplicates - change the button - got single. So this is not an IE7
thing. More browsers to test.
Wanted to make these comments to everyone who may have read this.
Thanks David for your comments.
--
Larry

Post by Larry
Thanks David.
Do you feel this is an issue where calling Microsoft support is in order?
If a report was made during beta, and the issue still exists, programming
around it is really not the solution - isit?
I realize we can probably program to avoid temporarily but we have potential
for over 1000 apps to have this problem with over 3000 users.
Yours thoughts are greatly appreciated - along with any other folks watching
in.
--
Larry

Post by David Wang

Post by Larry
Thank you for your response David. I am researching your suggestions.
In doing so, I'd like for you to reference a posting -
http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...
This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.
Any comment would be appreciated.
Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
- Application Redirects to itself after processing (somehow)
- Client auto-resubmit after encountering 200 0 64 (for whatever
reason)
- ASP.Net BrowseCap causes different behavior between IE6 and IE7
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

Hmm, sounds like an IE7 issue. It seems like the only way you can deal
with it is to session your POSTs so that you avoid duplicates.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//- Hide quoted text -

- Show quoted text -

[David Wang]

Post by Larry
The definition of the button uses the onClick event -
which should only occur once - right?

My point is that you are assuming:
document.getElementById('Form1'­).submit();

Does NOT end up invoking onClick event. I am not a Web Developer, but
I am not so certain of your assumption. Here's why.

I went and found the meaning of .submit() at:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357

It indicates that .submit() is supposed to "perform the same action as
a submit button". Now, it is not clear to me whether "perform the same
action as a submit button" is the same as "clicking on the submit
button" because I can see arguments both ways. One can say "onclick()
happens only on a real mouse click" or "onclick() of a submit button
happens whenever form submit happens".

For example, consider all the ways that one can trigger the submit
button:
- Use mouse to click on the submit button
- Use DOM to invoke the .submit()
- Hit "space" while tab focus is on the submit button
- Hit "enter" while the submit button is the default button of the
form

Not all of them involve actually clicking on the button. My question
to you is:
Do you expect "onClick" of a form submit button to be invoked whenever
user submits a form, regardless if they used the mouse to click on
anything?

In other words, if the user uses the keyboard to submit the form,
should they be able to skip around ShowProcessingMessage(). If they
can skip around ShowProcessingMessage(), then you won't see double
submit. If they can't skip around ShowProcessingMessage(), then you
are in an infinite loop situation and will see double submit.


Anyways, you are just noting that "onClick" behaves different on form
submit button between IE6 and IE7, and I suspect the reasoning is
along the lines of what I described above. Event based UI programming
is never easy.



//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Post by Larry
The definition of the button uses the onClick event - which should only occur
once - right? Why would this generate a loop condition? I think I might be
missing your point David.
Thanks
--
Larry

Post by David Wang
Glad you found the culprit. My gut feeling is that the issue is with
the code that you removed and not a bug in IE7 and other browsers.
I'm not a Web Developer, but I went looking for the meaning
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357
It indicates that calling .submit() is analogous to clicking the
submit button.
So, when the user clicks the <input> button with your existing code
<td align="right" width="50%">
<input class="btnNorm" type="submit" id="btnSend" value="Send"
style="WIDTH:72px; HEIGHT: 24px"
onclick="javascript:ShowProcessingMessage();document.getElementById('Form1'­).submit();">
</td>
1. Calls ShowProcessingMessage()
2. Trigger the Submit button -- which is this input button itself, so
- Calls ShowProcessingMessage()
- Trigger the Submit button -- which is this input button itself,
- Probably when the browser noticed the infinite loop and
stopped it, but not before two ShowProcessingMessage() (hence two
POSTs) has been invoked.
In my mind, ShowProcessingMessage() should have code to prevent itself
from being called multiple times since CSS/DOM can definitely cause it
to be called multiple times.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Post by Larry
I want to add some final comments on this issue -
We have found the culprit to our duplicate request problem -
The code within the form that defined the submit button and handled the
-------
<td align="right" width="50%">
72px; HEIGHT: 24px"
onclick="javascript:ShowProcessingMessage();
document.getElementById('Form1').submit();">
</td>
--------
Using IE6 this form submit sent a single request to the application - thus a
single email sent.
If you use IE7, everything else the same, the submit sent 2 requests to the
application - thus duplicate emails.
-------------
<td align="right" width="50%">
72px; HEIGHT: 24px">
</td>
-----------
IE6 sends a single AND IE7 sends a single.
Our developers should have caught this difference when they tested IE7 - but
they didn't. Suffice it to say - there is definitly a difference between IE6
and IE7.
Also, using Netscaler, the button configured 1 way sent 2, the other way
sent 1. Other brwosers yet to test.
Thanks.
--
Larry

Post by Larry
Would like to add some new comments here -
We believe we have found the culprit to this duplicate issue. It deals with
the way <input buttons are used. This may be a documented thing - but we
surely did not catch this. Here is an email from a developer working on this
case with me.
-----------
We have potentially solve the issue, we changed our form from <input
type="submit" to <input type="button" and had Sharon K. run an E-mail Quote
on TEST. This resulted in a single email sent. I then switched it back to
<input type="submit" and had her do this again, which resulted in duplicate
emails.
It seems the change to type="button" has temporarily solved the issue.
----------
Is this something that is documented - I'm going to find out. We were not
aware of it between IE6 and IE7. Maybe IE6 was more forgiving and IE7 isn't -
just not sure - YET.
Also I would like to point out that I tried this email app on Netscape v8
and got duplicates - change the button - got single. So this is not an IE7
thing. More browsers to test.
Wanted to make these comments to everyone who may have read this.
Thanks David for your comments.
--
Larry

Post by Larry
Thanks David.
Do you feel this is an issue where calling Microsoft support is in order?
If a report was made during beta, and the issue still exists, programming
around it is really not the solution - isit?
I realize we can probably program to avoid temporarily but we have potential
for over 1000 apps to have this problem with over 3000 users.
Yours thoughts are greatly appreciated - along with any other folks watching
in.
--
Larry

Post by Larry
Thank you for your response David. I am researching your suggestions.
In doing so, I'd like for you to reference a posting -
http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...
This was posted back in June of 2006 but it is exactly the problem I am
having with user of IE7. And it appears from this posting that in beta it was
reported.
Any comment would be appreciated.
Thank you.
--
Larry

Post by David Wang

Post by Larry
Hi,
I am having a "similar" situation. Let me explain why I "" quoted the word
similar.
I see the IIS log entries as has been noted in this posting. But the
situation that is causing these entries is different.
I have a .Net application that has been in production for months and months.
This is a web application that our users have used to send emails. Please let
me explain.
I work for an insurance company. An agent gets to our web site, enters
information to have an auto quote generated. When they submit thata
information for rating, the resulting premium is calculated and sent back to
the user in his borwser for viewing.
An option from that response quote page is a link, that when click will open
a new window where the agent can key in an email recipient's name, subject
and text message.
When ready, they click a submit button where the .Net email app runs,
generates the email at the .Net server and sends it. If it sends it
correctly, a response is sent to the user saying so.
Here's the problem -
If a user uses IE6, sends a request to this app to send an email, the app
sends 1 email to the recipient. If a user uses IE7 and sends a request to
send an email (same application that IE6 sent to), the app gets 2 requests
and sends 2 emails.
When you look at the IIS logs, and the borwser is IE6, there is 1 entry
where status is 200 0 0 etc. IFor IE7, there are 2 entries - the first is 200
0 64 and the second is 200 0 0
With IE7 always 2 requests - with IE6 always 1 request.
So, as I mentioned, same IIS log entry but how the entries are generated is
different.
I have researched what might be causing this and so far - nothing definite.
Is this an HTTP1.1 thing within IE7? My IIS server is WIndows 2003, .Net 1.1.
Any further discussion and/or help would be greatly appreciated.
Thank you - Larry
--
Larry

Post by Noemi

Post by David Wang
Client disconnect is only one possibility and there are others. Also,
just because Win32 error says 64 does not mean the client did not
receive the data. Networking is unpredictable like that - it is
possible for data to be transmitted to the client but the return ACK
for closing the connection gets lost, so the server thinks the client
never got the data when it actually did. Remember, the network is
inherently UNRELIABLE.

Hi. I've encountered similar logs when uploading fairly large files (> 2MB).
The application is a client-server app that does HTTP uploading. But
what's odd is that the error happens inconsistently.
a. When uploading large files from a client running on a WINXP os to a
server running on WIN 2K3 Enterprise Ed., the action completes successfully.
b. When uploading large files with the WIN 2K3 Enterprise Ed. machine as the
client and the server, the action throws a timeout error, and thus the
sc-win32-status 64 sc-status 200 log appears.
Can you shed some light why does this happen?
Thanks!- Hide quoted text -

- Show quoted text -

Something is causing duplicate requests to be sent to the .Net
application on the server. It is highly unlikely that IIS is
duplicating the request or log entry, so I would start looking at ways
for

...
read more »- Hide quoted text -
- Show quoted text -

[duangsamorn laplertsuk]

Dear all,
I just join in this newsgroups. I found this problem too
(sc-status=200 and sc-win32-status=64)
For my case, I have a new web application version. It works fine in UAT
environment, but in the production when my customer hit the web, the
server consume 100% cpu and memory. When I try to connect my production
page, my brower just silense and I found sc-status=200 and
sc-win32-status=64 in my iislog. When I read this article, I suspect
whether the programmer write the right header or not. But in IISLOG show
both normal successful access the page (sc-win32-status=0)and
sc-win32-status=64. Isn't it mean there is no problem with the
application? Have anyone give me advice ?
Laplertsuk



*** Sent via Developersdex http://www.developersdex.com ***

[David Wang]

Post by duangsamorn laplertsuk
Dear all,
I just join in this newsgroups. I found this problem too
(sc-status=200 and sc-win32-status=64)
For my case, I have a new web application version. It works fine in UAT
environment, but in the production when my customer hit the web, the
server consume 100% cpu and memory. When I try to connect my production
page, my brower just silense and I found sc-status=200 and
sc-win32-status=64 in my iislog. When I read this article, I suspect
whether the programmer write the right header or not. But in IISLOG show
both normal successful access the page (sc-win32-status=0)and
sc-win32-status=64. Isn't it mean there is no problem with the
application? Have anyone give me advice ?
Laplertsuk
*** Sent via Developersdexhttp://www.developersdex.com***

You can try to assume that the problem is not with the application,
but your symptoms suggest problems with the application. You will have
to debug it to figure out what is going on. IIS logs is simply
informing you of problems with the application.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//