IIS7 replacing CGI input payload with single S character

I've got an IIS server which runs my standalone CGI EXE application (no ASP or similar)

When switching from IIS6 to IIS7 I frequently begin getting one single "S" character as input, from IIS7, to this exe program, instead of the actual payload from the end user browser.

This only happens when https is used, and it only happens "sometimes" (I cannot see any "system" in that, but some users are more "hit" than others)


Any ideas why the IIS7 payload *sometimes* is replaced with one  single "S" character, when presented to the CGI standsalone program, by the IIS7 server, driven by a user https request?

/Stefan
(question edited; removed eventviewer message that was probably not related)
Stefan LennerbrantAsked:
Who is Participating?
 
Stefan LennerbrantConnect With a Mentor Author Commented:
The problem was eventually solved by continuing reading (trying over and over again) in the CGI script.

The root cause seems to be that IIS7 uses its setting "uploadReadAheadSize" to buffer input data to the script. When "enough" data has been read, about 40-50kb, the script is invoked.

Thus, when the script tries to read end user input, it might not yet be available. Changing the script to looping (for at least some seconds) to really retrieve all data as specified in CONTENT_LENGTH, solves the problem.

Increasing the IIS7 uploadReadAheadSize setting is another method, of course.
0
 
Stefan LennerbrantAuthor Commented:
This is really annoying! I cannot find anything on the internet, but I mean, IIS7 exchanging the request payload with an "S" character only, that seems so far-fletched that it probably  should be easily remembered by someone... :-)

Are there any limitation settings in IIS7 that relates to https requests, setting max limits on concurrent requests etc etc?
There are not that many requests on this server (like less than one per second, even though it of course may be more from time to time) and the requests (at least the ones that trigger the error) are small, no large data volumes.

The failing requests use method POST and encoding application/x-www-form-urlencoded
Note that some requests (often) works OK and some requests don't. Looks quite random.
0
 
ahoffmannCommented:
can you post such a POST request?
use LiveHTTPHeader add-on in firefox or something proper for IE
0
 
Stefan LennerbrantAuthor Commented:
Further investigation indicates that the problem seems to be that the end user data is not available at the time when the CGI application is launched
Thus, when the CGI program reads it (standard input) from IIS7, only one character is available, and is read.

I am looking into if some config setting in IIS7 gives this behaviour, that "input buffering" is kind of disabled (just as response buffering may be disabled, for output), such that IIS7 is not able to present all input user data at the time the CGI program is starting.

Also, I detected one (single) situation now where environment variable CONTENT_TYPE was empty (as set by IIS7) even though CONTENT_LENGTH was non-zero.
I have never seen that before, and thus I wonder if this also may be due to the fact that the content-type setting has not been received/identified by IIS7 when the CGI program was launched.

Strange?
I'm continuing investigating. Does it even exist a "disable INPUT buffering to CGI" config setting in IIS7?
0
 
Stefan LennerbrantAuthor Commented:
Eventually solved
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.