Cannot get running from CGI directory

I'm guessing I'm missing something obvious but here goes.

I installed apache on SLES10SP2 via the RPMs with SLES10SP2.  By default it looks like document root is /srv/www/htdocs and CGI-BIN is /srv/www/cgi-bin

contents of /srv/www/cgi-bin are
testserv:/srv/www/cgi-bin # ls -1
testserv:/srv/www/cgi-bin #

test.cgi and are scripts I put in myself.  The rest were installed with the RPM.  Loading the other CGI scripts in browser works but loading in test.cgi and do not

My browser gets a pop up window saying:

"You have chosen to open which is a Perl script" and then "What should firefox do with this file?"

The only thing I could think of was that it didn't recognize .cgi or .pl.  

If I grep in mime.types I get:

testserv:/etc/apache2 # grep -i perl mime.types
application/x-perl pl pm al perl
testserv:/etc/apache2 # grep -i cgi mime.types
application/x-cgi cgi
testserv:/etc/apache2 #

I also added

AddHandler cgi-script .pl .cgi

in the default-server.conf file right under the DocumentRoot statement.  Still no go (the apache configuration is spread amongst many different *.conf files it seems when installing from RPM).

Anyhow, any ideas or thoughts?  

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

uaynebAuthor Commented:
more info on the script itself. and test.cgi are the same

testserv:/srv/www/cgi-bin # cat

print "Content-type:/text/html\n\n";
print "hello world\n";

testserv:/srv/www/cgi-bin # ls -l
-rwxr-xr-x 1 root root 77 Apr 21 01:27
testserv:/srv/www/cgi-bin #

uaynebAuthor Commented:
More info - is it something with my browser?  When i telnet to port 80 and do a
GET /cgi-bin/

it's fine.  I added a print out of localtime() in the script just so I could see it getting a new datestamp each time I tried to access the perl script.

Also no errorlog entries.  

testone:~ # telnet 80
Connected to
Escape character is '^]'.
GET /cgi-bin/
hello world
 date: Wed Apr 21 02:14:01 2010
<br>Connection closed by foreign host.
testone:~ #

kinda stumped :(
It should'nt really be a browser issue.

Either your server executes the cgi-script ot if badly configured it serves the contents.

What you could check though:

 Did you flush your browser's cache?
It might be, that you fixed somehting in the server, but that your browser still returns the old data.

What might be as well is, that your browser is configured for virtual servers and that your
simple telnet request falls into the default configuration, whereas your browser request falls into another config.

What's the url  you entered in the browser?

did you try the same url with wget?
THis should allow you to eliminate the browser as culprit

Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

uaynebAuthor Commented:
I didn't try the wget yet, just telnet locally to port 80.  That's what lead me to believe it might be a browser issue.

Wget transfers the files and saves them locally.

Also, yes that is the URL I entered in my browser

Thanks for the tips - any other ideas?
Are you sure the you posted is the one you are getting?  From your telnet output, it doesn't look like you are getting the content-type header - which would explain why firefox is asking you to download the file, rather than display it.  Also, the output includes "<br>" lines and a date line; the perl script you posted does have the content-type header, but no "<br>", and no date, so it looks like you are getting a different script.

Try double-checking for any Alias or ScriptAlias directives in you apache config files.  You could also try posting here your config files.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
In order to be sure, you really get what you think you are fetching, you could
rename the perl script, restart apache and try with your browser and tyry with telnet again and with wget.

you could try folowing wget command:
wget -S -O -

It will print out the headers returned by your server and print the file to stdout instead of saving it to a file.

I'd suggest you check what result you get with wgetn and post it here.

By the way: Did you try to clear the cache of your browser?
uaynebAuthor Commented:
Hi there,
i did change the script to include newlines, etc... in between my first post and the next post.  Sorry I did not mention that.  Good thought.   Yes it is the same script.

Anyway, so what it ended up being is at typo.  In a haze of loopiness I thought "well maybe my content-type is not correct and it should be mime something or perl something" which shows you how loopy I was because of course it is supposed to be text/html, not sure why I doubted it.

But anyway, because of my haze of loopiness I checked the Content-type and from there spotted my typo:

print "Content-type:/text/html\n\n";

Should be

print "Content-type:text/html\n\n";

(no forward slash before the word "text")

And it worked :D

Thanks guys!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Scripting Languages

From novice to tech pro — start learning today.