Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Unexpected "text/plain" output with cgi

by Samn (Monk)
on Nov 13, 2002 at 17:02 UTC ( #212629=perlquestion: print w/replies, xml ) Need Help??

Samn has asked for the wisdom of the Perl Monks concerning the following question:

I'm reworking my perl driven site and have managed to create a perplexing new error. The output of my pages comes as a "Text Dociment" instead of an HTML document.

Displays just fine in all browsers, and is (almost) W3C verified. But when accessing any of the pages on the site like

It is apparently transmitted as a text document. In IE this renders flawlessly, but the W3C validator on the page says it can not be parsed. As well, Mozilla based browsers just display the HTML code instead of rendering it as a webpage.

A novice, I'm baffled and don't even know where to begin.

My index.cgi looks to see if it has been passed a "page=" variable. If it has, it runs the specified subroutine. Many of the pages/subroutines are complex with database calls and what not, but the specific one above ("kittens") is only a single print statement.

If no "page=" is specified, index.cgi does nothing and leaves the main HTML cell empty.

Where should I start with this?

=== Illustration of index.cgi:
<code> #!/usr/bin/perl require *.rs; # files that contain one subroutine each print qq~ <html> <layout> ~; if ($page) { &$page; } print qq~ <layout> </html> ~;

  • Comment on Unexpected "text/plain" output with cgi

Replies are listed 'Best First'.
Re: Unexpected "text/plain" output with cgi
by janjan (Beadle) on Nov 13, 2002 at 17:15 UTC
    You can always explicitly send a header -- it doesn't look like you're doing that. makes it easy:
    print $q->header('text/html');
    perldoc CGI for more on this. Or, you can send your header manually:
    print "Content-type: text/html\n\n";
    Other than that, I'm not sure why the Mozilla browsers aren't rendering the code. Perhaps posting the contents of the $page variable or the *.rs files would help.
Re: Unexpected "text/plain" output with cgi
by enoch (Chaplain) on Nov 13, 2002 at 17:48 UTC
    Since no one has pointed it out, yet, you really really, really do not want to do:
    if ($page) { &$page; }
    What if someone (and, don't do this) passed in the URL;`rm -rf /etc` (or worse). A better way would be to:
    if($page) { SWITCH: { &kitten, last SWITCH if($page eq 'kitten'); &foo, last SWITCH if($page eq 'foo'); &bar, last SWITCH if($page eq 'bar'); . . . print STDERR "invalid CGI parameter", last SWITCH; } }

Re: Unexpected "text/plain" output with cgi
by iburrell (Chaplain) on Nov 13, 2002 at 17:22 UTC
    You need to send back the HTTP header before sending any HTML. You may be doing this but it isn't happening for the code path that prints the secondary pages. Specifically, you need to set Content-Type header to text/html. Otherwise, Apache sets the default to text/plain which is what is showing up on your link above. The easiest way to do this is with the module's header method.
    use CGI; print header;

    IE is broken and recognizes the document is HTML and displays it as a web page. Mozilla is behaving properly and shows the HTML as plaintext like the server told it to.

      I guess you meant something like
      use CGI qw(:standard);
      Otherwise the header function won't be exported into your namespace.


Re: Unexpected "text/plain" output with cgi
by fglock (Vicar) on Nov 13, 2002 at 17:53 UTC

    Interesting. Your HEAD is obviously wrong, maybe caused by something in your "*.rs" line.

    It shows:

    200 OK Connection: close Date: Wed, 13 Nov 2002 17:50:18 GMT Server: Apache/1.3.26 (Unix) PHP/4.2.2 mod_gzip/ Content-Type: text/plain Client-Date: Wed, 13 Nov 2002 16:36:49 GMT Client-Junk: loading<br>loading<br>loading cleanmails<br>loading<br>loading<br>loading<b +r>loading<br>loading<br>loading<br>loadin +g<br>loading<br>loading<br>loadin +g<br>loading<br>loading<br>loading<b +r>loading<br>loading<br>loading glossary<br>loading<br>loading<br>loading<br>loa +ding<br>loading<br>loading<br>loading<br>loading<br>loading<br>loading babbl<br>loading<br>loading<br>loading<br>loading<br>loading<br>load +ing<br>loading<br>loading<br>loading truth<br>loading<br>loading<br>loading +<br>loading<br>loading<br>loading update_syste<br>loading<br>loading<br>loading ski<br>loading<br>loading<br>loading +<br>loading<br>loading<br>loading send_note. +rs<br>loading<br>loading<br>loading scor<br>loading<br>loading<br>loading jess<br>loading<br>loading<br>loading j<br>loading<br>loading<br>loading thetea<br>loading<br>Content-type: text/html Client-Response-Num: 1
Re: Unexpected "text/plain" output with cgi
by Samn (Monk) on Nov 13, 2002 at 18:00 UTC
    Thanks for the input guys. The first thing that index.cgi always prints is

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

    I'll let do it instead and see how that works out.

    And I know running &$variable is, in a word, "retarded." I'm going to switch it to checking to see if the file exists, then requiring it then running it. Gracia!

Re: Unexpected "text/plain" output with cgi
by Mr. Muskrat (Canon) on Nov 13, 2002 at 17:19 UTC

    If it is transmitted as a text document, then your cgi script is setting a plain text content-type header...

    Show us the real code please, not psueodocode.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://212629]
Approved by talexb
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2023-11-30 08:06 GMT
Find Nodes?
    Voting Booth?

    No recent polls found