IIS6 CGI EXEC Problem

Clint · #1 (**permalink**) 03-08-06, 04:55 PM

Alright, I just upgraded my webserver to IIS6 finally.

So far it's been hell. I have a lot of code to review, and a lot of work to perform before I'm actually going to be done with this upgrade.

Unfortunately this problem is just driving me insane.

I have a .STM page with a EXEC CGI in it calling a .ASP page like this:

Code:

<html>
<head>
<title>Untitled</title>
</head>
<body>
<!--#exec cgi="/scripts/blah.asp"-->
</body>
</html>

The .ASP page has code in it to output the word "BLAH" into the HTML output stream, much like this:

Code:

<%
response.write("BLAH")
%>

When I go to my .STM page the .STM page is executed and the output is written into the output of the .STM page just as it should be....
EXCEPT THAT
the output is prefixed by the length of the string outputted from the .ASP page in Hex, and then the output string and then a 0. Much like this:
4 BLAH 0

Even when I output an emptry string ("") from the .ASP page, I get a 0 on the .STM page.

More importantly I have a .ASP counter page that returns the images necessary to create a nice graphicale counter, but it doesn't look right when the output has 'D2' (210 charachters in hex) then the numbered images (via HTML IMG tags), and then a '0'.

If anyone else ever ran into this, or has any idea what IIS6 is doing, please let me know.

#2 (**permalink**) 03-09-06, 06:29 AM

i've never seen that. my question is why are you using a .stm (not sure what type of file that is) to execute an asp page when it is supported natively by iis

Clint · #3 (**permalink**) 03-09-06, 11:31 AM

I need to do an #EXEC CGI to execute the underlying .ASP file with querystring parameters sent to it through the path. You can only perform #EXEC CGI on a .STM page.

I.E. The path would be something like:
/scripts/counter.asp?type=LED&page=Projects

That way I can send my generic .ASP counter, the data about that page it is being called from.

Querystring arguments cannot be passed through a #include. If I do a #include inside a .ASP file to a .ASP file, it will fail because you can't reference another file using #include, when there are querystring arguments.

This causes an error when inside a .ASP file:


Keep in mind, that my process worked just fine on my Win2K Server with IIS5 before I upgraded to Win2k3 Server with IIS6. And for the most part it is still working except for the additional information in hex about the length of my returned string.

I have this #EXEC CGI call on about 60 individual sections of my website, with different parameters being sent on each.

So if you have another way to fix my problem, without me having to a GREP for '#EXEC CGI', and then open the 60 files it finds and change how the counter call works, I would greatly appreciate it.

#4 (**permalink**) 03-09-06, 01:30 PM

i personaly write counters differently. i would be taking advantage of the global.asa(x) and then just using asp pages to display asp information.

you can pass a querystring value to a included file.
<% myvar = request.querystrion("val") %>


then in the file.ext reference the myvar

Clint · #5 (**permalink**) 03-09-06, 02:51 PM

So your suggestion is to take this line in all 60+ of my .STM pages:



and turn it into:

<%
varUserID = "WEBMASTER"
varName = "CE_MFCCAM"
varStyle = "eggs"
varWidth = 7
varInc = 1
varHide = 0
%>


And save them all as .ASP even though, the only ASP code in them is this fix.

Quote:

So if you have another way to fix my problem, without me having to do a GREP for '#EXEC CGI', and then open the 60+ files it finds and change how the counter call works, I would greatly appreciate it.

#6 (**permalink**) 03-09-06, 03:04 PM

nope, i try to stick to one format and not intermix or be dependent on another component to solve a problem. you could use an iframe.

or from another site they sugest

Code:

<!-- #include file = "test.asp" -->

instead of using <!--#exec cgi....

Clint · #7 (**permalink**) 03-09-06, 04:17 PM

I need a simple, easy, quick solution.

As I said before, this did work, and now I've upgraded to IIS6 and now it doesn't. I want to know if anyone has had this problem, and how they fixed it.

I already know plenty of tedious ways to fix it, and this suggestion is not even remotely close to the easiest.

Obviously you don't understand what I'm trying to do, or the error that I am getting. And you definitely have not been reading my posts, or you would have already realized this.

I'm not intermixing formats, at least by IIS standards. Both file types are valid in IIS, the only difference is that a .STM has tags in it that signify executable parts, and .ASP has executable script in it, but ABSOLUTELY NOT the other way around. I can't do EXEC CGI in an .ASP page, and I can't do '#INCLUDE FILE/VIRTUAL' on a .STM page, so your suggestion involves a lot of extra work, for the little it accomplishes. I'm simply trying to execute some Servers Side script that is located in a common area of my site, from a page that DOES NOT CONTAIN ASP server side script. Most of my users, are not experienced with ASP (hence the .STM file and the EXEC call), so this is a simple solution for them to have a dynamic counter on their page, without learning ASP. If they suddenly found .ASP files instead of .STM files in their web space that contained ASP code they didn't understand, well they would probably freak out, and I would have an even larger problem on my hands than before.

An IFRAME gets me nowhere, I don't have a problem with my HTML. Also, '#include file' and '#include virtual' do the same thing except one uses relative file paths, and the other uses IIS virtual directory paths.

When I posted to this forum I hoped I would get a response, from somebody who had experience it before, and could give me some useful input.

I DID NOT POST to hear "WHY? WHY? WHY?" about these methods. Nor did I post to be ridiculed because of the way a formerly working piece of code is structured. If it weren't right, then it would have never worked in the first place. I didn't write this code anyhow, I'm just in charge of service if something goes wrong.

If you haven't had this problem yourself, or you don't know the internal workings of IIS6, then you can't help me. And, if you are so hung up on WHY I am doing this, you need to go into Philosophy/Psychology, and get the hell out of coding, because you can't help any programmers with that kind of attitude.

I'm sorry if I offended anyone, but I'm very stressed about this upgrade (downgrade!) from hell. I've been working for many days straight making sure the 308,000 documents that are on my server are working correctly, and I think I'm at the end of my rope.

Quote:

So if you have another way to fix my problem, without me having to do a GREP for '#EXEC CGI', and then open the 60+ files it finds and change how the counter call works, I would greatly appreciate it.

mab · #8 (**permalink**) 03-09-06, 05:55 PM

Searching the Internet in general turns up two possibilities -

1) Try changing -  to pass parameters to a script.

mab · #9 (**permalink**) 03-09-06, 10:39 PM

I think I have figured out what it is doing, but why is sill anybodies guess.

The classic definition of a string is the 1st byte is the length, followed by the characters of the string, with a zero byte terminator. For whatever reason, your code is treating this as an array of values instead of a string.

Perhaps there is some setting as to what is considered as a string?

Clint · #10 (**permalink**) 03-10-06, 04:20 PM

THANK YOU MAB!

Your posting with a link to support.microsuck.com had the answer, although not exactly as they had stated it.

RESOLUTION

Turn off buffering in IIS.
Turn off buffering on the called pages. To do this, set Response.Buffer to False at the top of the pages that #exec calls. This causes buffering to be turned off on these pages, but still allows buffering for the site.
Flush the buffer before it responds to #exec. To do this, place the Response.Flush command at the top of the pages that #exec calls.

The first option won't work for me, so I skipped that.

The second option suggests turning off the buffer using "response.Buffer = false". This changed nothing in my case.

The Third option is to flush the buffer using "response.Flush()". This option gave me an error. When I tracked down the specific error, I found out that to do a Flush() you have to have buffering enabled. HMMMM!

So at the top of my .ASP that's called by the #EXEC CGI I put:
response.Buffer = True
response.Flush

It's pretty much the opposite of the second option, implemented right before the third option.

So now, THERE ARE NO SPECIAL HEX VALUES or TRAILING 0!

I agree, I have no idea WHY it works when I do that, but again, THANK YOU MAB for your link, and suggestions.