I was just curious with how people using IIS are dealing with duplicate requests when the socket connection goes away and the browser re-submits the request?
I see this frequently in the IIS logs represented by the first request getting a sc-status of 200 along with a sc-win32-status of 64. Generally the second request comes in within a few milliseconds of the first and gets a sc-status of 200 and sc-win32-status of 0. Many times while the first request is still processing when the second comes in.
For the most part, this doesn’t present a problem, but if the request was a POST and expected to change something in the database, it can cause “issues” if not trapped and handled properly. I’d much rather trap these duplicates before trying to hit the database, but I’m not sure of the best approach. Currently I’m logging a ton of info within the onRequestStart() and onRequestEnd() functions to try and get a better handle on the problem.
Considering the socket no longer exists for the first request, it will be that second request that will need to tell the user “something”.
Thoughts?