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.
On Mar 26, 2:26 pm, "WalterWalt" <,> wrote:
> 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
//
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 Choice
http://www.eggheadcafe.com
On Apr 5, 12:35 am, Andrei wrote:
> 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
//
On Apr 5, 12:10 pm, "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
On Apr 5, 5:41 am, adanil...@gmail.com wrote:
> On Apr 5, 12:10 pm, "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
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
//
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
On Apr 9, 2:14 pm, adanil...@gmail.com wrote:
> 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
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
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
//
On Apr 10, 8:05 am, adanil...@gmail.com wrote:
> 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
On Apr 10, 10:20 pm, "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
Last update.
Unfortunatelly can't reproduce "200 0 64" with Fiddler.
Thanks,
Andrei
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
[standard app xml response]
Could you suggest why is it so?
Many thanks,
Andrei
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
//
On Apr 11, 8:37 am, adanil...@gmail.com wrote:
> 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
>
>
> [standard app xml response]
>
> Could you suggest why is it so?
>
> Many thanks,
> Andrei
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
On Apr 11, 9:21 pm, "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
>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David. Wang
> //
>
> On Apr 11, 8:37 am, adanil...@gmail.com wrote:
>
>
>
> > 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
>
> >
> > [standard app xml response]
>
> > Could you suggest why is it so?
>
> > Many thanks,
> > Andrei- Hide quoted text -
>
> - Show quoted text -
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"
%>
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.
On Apr 12, 6:47 am, adanil...@gmail.com wrote:
> 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.
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
//
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.
> 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.
> 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
Hope above helps to help me :)
Thank you,
Andrei
Colleagues, any ideas?
Thank you in advance,
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.
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!
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
"Noemi" wrote:
> > 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!
On May 16, 11:23 am, 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
>
>
>
> "Noemi" wrote:
> > > 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!- 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
//
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/d efault.aspx?mid=6a92c456-a435-4c52-b58b-6534a5db1563&dg=micr osoft.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
"David Wang" wrote:
> On May 16, 11:23 am, 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
> >
> >
> >
> > "Noemi" wrote:
> > > > 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!- 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
> //
>
>
On May 17, 11:51 am, 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/d efault.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
>
>
>
> "David Wang" wrote:
> > On May 16, 11:23 am, 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
>
> > > "Noemi" wrote:
> > > > > 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!- 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
> > //- 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
//
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
"David Wang" wrote:
> On May 17, 11:51 am, 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/d efault.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
> >
> >
> >
> > "David Wang" wrote:
> > > On May 16, 11:23 am, 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
> >
> > > > "Noemi" wrote:
> > > > > > 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!- 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
> > > //- 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
> //
>
>
Would like to add some new comments here -
We believe we have found the culprit to this duplicate issue. It deals with
the way
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
type="submit" to
on TEST. This resulted in a single email sent. I then switched it back to
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
"Larry" wrote:
> 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
>
>
> "David Wang" wrote:
>
> > On May 17, 11:51 am, 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/d efault.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
> > >
> > >
> > >
> > > "David Wang" wrote:
> > > > On May 16, 11:23 am, 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
> > >
> > > > > "Noemi" wrote:
> > > > > > > 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!- 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
> > > > //- 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
> > //
> >
> >
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:
-------
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 button with your existing code
of:
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
"David Wang" wrote:
> 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 button with your existing code
> of:
>
>
> 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'=AD).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
//
On May 21, 8:39 am, Larry
> The definition of the button uses the onClick event - which should only o=
ccur
> once - right? Why would this generate a loop condition? I think I might be
> missing your point David.
>
> Thanks
> --
> Larry
>
>
>
> "David Wang" wrote:
> > 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 button with your existing code
> > of:
>
> >
> >
> > style=3D"WIDTH:72px; HEIGHT: 24px"
> > onclick=3D"javascript:ShowProcessingMessage();document.getEl ementById('=
Form1'=AD).submit();">
> >
>
> > 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
> > //
>
> > On May 18, 10:26 am, 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 t=
he
> > > reqeust to the app that sent an email was:
> > > -------
> > >
> > >
" style=3D"WIDTH:
> > > 72px; HEIGHT: 24px"
> > > onclick=3D"javascript:ShowProcessingMessage();
> > > document.getElementById('Form1').submit();">
> > >
> > > --------
>
> > > 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:
> > > -------------
> > >
> > >
" style=3D"WIDTH:
> > > 72px; HEIGHT: 24px">
> > >
> > > -----------
>
> > > IE6 sends a single AND IE7 sends a single.
>
> > > Our developers should have caught this difference when they tested IE=
7 - but
> > > they didn't. Suffice it to say - there is definitly a difference betw=
een 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
>
> > > "Larry" wrote:
> > > > Would like to add some new comments here -
>
> > > > We believe we have found the culprit to this duplicate issue. It de=
als with
> > > > the way
ut we
> > > > surely did not catch this. Here is an email from a developer workin=
g on this
> > > > case with me.
> > > > -----------
> > > > We have potentially solve the issue, we changed our form from
> > > > on TEST. This resulted in a single email sent. I then switched it=
back to
> > > >
duplicate
> > > > emails.
>
> > > > It seems the change to type=3D"button" has temporarily solved the i=
ssue.
> > > > ----------
>
> > > > Is this something that is documented - I'm going to find out. We we=
re not
> > > > aware of it between IE6 and IE7. Maybe IE6 was more forgiving and I=
E7 isn't -
> > > > just not sure - YET.
>
> > > > Also I would like to point out that I tried this email app on Netsc=
ape 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
>
> > > > "Larry" wrote:
>
> > > > > Thanks David.
>
> > > > > Do you feel this is an issue where calling Microsoft support is i=
n order?
>
> > > > > If a report was made during beta, and the issue still exists, pro=
gramming
> > > > > around it is really not the solution - isit?
>
> > > > > I realize we can probably program to avoid temporarily but we hav=
e potential
> > > > > for over 1000 apps to have this problem with over 3000 users.
>
> > > > > Yours thoughts are greatly appreciated - along with any other fol=
ks watching
> > > > > in.
> > > > > --
> > > > > Larry
>
> > > > > "David Wang" wrote:
>
> > > > > > On May 17, 11:51 am, Larry
> > > > > > > Thank you for your response David. I am researching your sugg=
estions.
>
> > > > > > > In doing so, I'd like for you to reference a posting -
>
> > > > > > >http://www.microsoft.com/communities/newsgroups/list/en-us/ def=
ault.as...
>
> > > > > > > This was posted back in June of 2006 but it is exactly the pr=
oblem I am
> > > > > > > having with user of IE7. And it appears from this posting tha=
t in beta it was
> > > > > > > reported.
>
> > > > > > > Any comment would be appreciated.
>
> > > > > > > Thank you.
> > > > > > > --
> > > > > > > Larry
>
> > > > > > > "David Wang" wrote:
> > > > > > > > On May 16, 11:23 am, 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 posti=
ng. 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 sen=
d 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 su=
bmit thata
> > > > > > > > > information for rating, the resulting premium is calculat=
ed and sent back to
> > > > > > > > > the user in his borwser for viewing.
>
> > > > > > > > > An option from that response quote page is a link, that w=
hen click will open
> > > > > > > > > a new window where the agent can key in an email recipien=
t's name, subject
> > > > > > > > > and text message.
>
> > > > > > > > > When ready, they click a submit button where the .Net ema=
il app runs,
> > > > > > > > > generates the email at the .Net server and sends it. If i=
t 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 a=
n email, the app
> > > > > > > > > sends 1 email to the recipient. If a user uses IE7 and se=
nds a request to
> > > > > > > > > send an email (same application that IE6 sent to), the ap=
p gets 2 requests
> > > > > > > > > and sends 2 emails.
>
> > > > > > > > > When you look at the IIS logs, and the borwser is IE6, th=
ere is 1 entry
> > > > > > > > > where status is 200 0 0 etc. IFor IE7, there are 2 entrie=
s - 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 entrie=
s 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 WIn=
dows 2003, .Net 1.1.
>
> > > > > > > > > Any further discussion and/or help would be greatly appre=
ciated.
>
> > > > > > > > > Thank you - Larry
> > > > > > > > > --
> > > > > > > > > Larry
>
> > > > > > > > > "Noemi" wrote:
> > > > > > > > > > > Client disconnect is only one possibility and there a=
re others. Also,
> > > > > > > > > > > just because Win32 error says 64 does not mean the cl=
ient did not
> > > > > > > > > > > receive the data. Networking is unpredictable like th=
at - it is
> > > > > > > > > > > possible for data to be transmitted to the client but=
the return ACK
> > > > > > > > > > > for closing the connection gets lost, so the server t=
hinks the client
> > > > > > > > > > > never got the data when it actually did. Remember, th=
e 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 co=
mpletes successfully.
> > > > > > > > > > b. When uploading large files with the WIN 2K3 Enterpri=
se Ed. machine as the
> > > > > > > > > > client and the server, the action throws a timeout erro=
r, 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 look=
ing at ways
> > > > > > > > for
>
> ...
>
> read more =BB- Hide quoted text -
>
> - Show quoted text -
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 ***
On Aug 22, 1:22 am, 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
//