when you do $cgi->header('test/plain'), it's not going to send a Content-Type header that the browser recognizes, hence the browser's offer to save the stream rather than just displaying.

As for the rest of your post, why would you send $cgi->header('test/plain'? what is it you're trying to aoomplish? what does "seems to work just about normal." mean? Your questions are not answerable if they are not comprehensible.

All code given here is UNTESTED unless otherwise stated.

Sorry, let me try again. I typed too fast on this node, hence the mistakes. The issue is that:

$cgi->header('text/plain');
[download]

Gives me the HTTP 200 (but doesn't show any subsequent print statements), while

$cgi->header('text/plain'), "\n";
[download]

Allows the page to render normally.

---

You asked what I am trying to do: I have many scripts that outputs to a text-file. Rather than reformatting for the web, I would like to just add code to the top like:

use CGI;
$cgi->header('text/plain');
[download]

and have the text show up, just as it would if it had been giving output to screen.

At the risk of being annoying, here is an example of my second pint

use CGI qw/:standard/;
my $cgi = new CGI;
print $cgi->header('text/plain');
print "testing\n";
[download]

I had believed that this would display simply "testing" within the browser window. That isn't the case -- it attempts to download the output -- but I haven't been able to figure out why, or how to change this behaviour

use CGI qw(header);
print header(-type=>'text/plain');
print header(-type=>'test/plain');

__END__

OUTPUT: 

Content-type: text/plain; charset=ISO-8859-1

Content-type: test/plain
[download]

I am not sure why you want to print out a Content-type header that isn't a valid MIME type.

</ajdelore>

Good morning all,

After a night of reflection, I realized what the problem might be. I have this issue solved, now, but I don't understand my solution.

The basic problem was this: if I used a form-submit button to access a CGI page that used a 'text/plain' HTTP header, the browser wanted to download rather than display. Several monks, having patience with my poor explanations, indicated that it worked fine on their systems.

And, indeed, when I changed the code that called this text-returning CGI script from a form to a link, the browser happily rendered the page.

Apparently, there is something "different" about how a form behaves from a link. So, I checked if this was a GET vs. POST difference, and indeed it is. That surprised me: in my mind GET & POST were basically interchangeable, but POST made a "prettier" URL.

I google'd a bit, and only ran across basic explanations of the GET/POST, nothing that seemed to explain this kind of difference. Can anyone offer any suggestions on where to look to find more information, or on what's going on?

Of course, after I post I find something useful. The important part of this is:

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

So I suppose the problem is that returning a 'text/plain' stream as the result of a POST is not something that can be identified by a URI. In other words: POST should only return HTML, then?