Re: CGI under IIS throws away printf on multiple posts.

From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 03/22/05 

Date: Tue, 22 Mar 2005 13:23:22 -0800

I'm sorry, but your description is exactly what *should* happen given what
you have engineered. IIS is not throwing away anything. It looks like it is
a lack of engineering in the CGI application that is causing your current
Server Down.

For example, the double submit issue happens against an ordinary ASP page as
well, but as soon as you use ASP Sessions, it is no longer possible. Same
exact IIS, same exact ASP page, just different feature within ASP -- you can
serialize requests to the application for that session. Which is what you
will have to implement in CGI, by taking a server-side lock to prevent the
session from performing the operation a second consecutive time.

Regarding the three solutions you proposed:
> 1) Force IIS to NOT throw away/forget the output for the 1st CGI instance.
> 2) Force IIS to NOT invoke a second CGI instance for the same session.
> 3) Possible use ASPSESSIONID in the HTML headers to insure that the
> client does not post twice on the same session.

1. It is the browser that is throwing away the response since it considers
the output to the last submit as important
2. "Session" is an application-level concept, which IIS supports but has no
notion about. Thus it is not possible for IIS to serialize CGI instances per
"application session" (IIS is a high-performance server. Asynchronous and
parallel request processing is the desired default behavior). It is
therefore the responsibility of the CGI to serialize. ASP and ASP.Net are
example ISAPIs that can perfectly serialize according to their application
session concept. You will need to do the same.
3. This is for your code to figure out. ASP will already serialize
correctly, but since anyone can POST to the CGI, you have a potential
security issue if the CGI does not serialize independently of being called
from ASP (since it is web-accessible and anyone can invoke it and attack
you).

Regarding your attempted solution:
> 1) We tried detecting if the CGI is being invoked for the same session,
> and if so, for the 2nd session to return NOTHING

This is just the wrong way to resolve the issue, and the results prove it.
Quite contrary, it absolutely does NOT prove IIS did anything wrong; it
proves that your CGI did the wrong thing. From browser perspective, it gets
two responses, the first response and a second empty response. Since the
second one happened in response to the latter submit, the browser can treat
it as the "real" response -- and error out on the empty response.

Here is one suggestion on how to solve your issue:
Implement a session-based lock in the server-side code, and the first submit
takes the lock (and then does work, and on return, releases the lock), while
any subsequent requests over the same application session will cause the
server-side code to return a "busy" web page while the lock is held. When
the lock is returned, the server-side app will return a "completed" web page
and the app continues to run. The busy page frequently will meta redirect
back to the server-side code to show "status" (and the final "completed")
web page. Other varieties exist, but you get the general idea.

Hopefully, it is now clear that your CGI application is the cause of your
problems. 

-- 
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"ATS" <ATS@discussions.microsoft.com> wrote in message
news:1594C614-DE78-4263-9C14-9C5AC9E1BBFD@microsoft.com...
PRB: CGI under IIS throws away printf on multiple posts.
Please help,
We have a Server down issue.
We have just discovered a terrible problem with a CGI application of ours.
We have HTML that gets posted multiple time for the same browser session
because a user clicks the ENTER key or double clicks on a submit button very
fast, and their browser (which varies from IE to other browser types) posts
the same form twice, causing our CGI application to get posted to twice for
the same data. We have traced that what happens in this situation is that
IIS
somehow gets the second post to override the 1st post, causing the output of
the 1st instance of our CGI app to be ignored/lost/forgotten, in favor of
the
2nd instance of our CGI app.
This is causing us to have a Server down issue in that the 2nd instance
returns an invalid response back. We have seen this behaviour on IIS for XP
with SP2, and Windows Server 2000, so it is not isolated to any service pack
as far as we know.
We believe this PRB can be solved in these ways:
1) Force IIS to NOT throw away/forget the output for the 1st CGI instance.
2) Force IIS to NOT invoke a second CGI instance for the same session.
3) Possible use ASPSESSIONID in the HTML headers to insure that the client
does not post twice on the same session.
Things we have tried and failed:
1) We tried detecting if the CGI is being invoked for the same session, and
if so, for the 2nd session to return NOTHING (I.E. it never calls printf),
while the 1st instance is still running. This failed, as NO HTML output was
returned to the client, which of course caused a CGI error to the client.
This prooved that IIS was throwing away/forgetting the output of the 1st
instance in favor of the 2nd.
Any ideas would be greatly appreciated.