RE: cgi_to_mod_perl manpage suggestion
On Wed, 14 Mar 2001, Perrin Harkins wrote:
On Wed, 14 Mar 2001, Issac Goldstand wrote:
I still think that the above line is confusing: It is
because mod_perl is
not sending headers by itelf, but rather your script must provide the
headers (to be returned by mod_perl). However, when you just
say "mod_perl
will send headers" it is misleading; it seems to indeicate
that mod_perl
will send "Content-Type: text/html\r\n\r\n" all by itself, and that
conversely, to disable that PerlSendHeaders should be Off.
Would it help if it said "PerlSendHeader On makes mod_perl act just like
CGI with regard to headers"?
A small correction: "PerlSendHeader On makes mod_perl act just like
mod_cgi with regard to HTTP headers" :)
CGI is a protocol...
Hmm. What nobody seems to be mentioning explicitly (for the newbees who
would benefit from this discussion) are the things that
mod_cgi/PerlSendHeaders *DO*, that otherwise would have to be done manually.
Or, to put it more succinctly, what is the *exact* difference in headers
between PerlSendHeaders On and Off (which happen to be the same difference
as between a regular CGI script and an NPH script)?
It seems like almost all of the available documentation assumes that A) you
already know, or B) you don't need to know.
So at the risk of seeming bold, and understanding that this summary *is*
going to be incomplete:
There is a similarity of requirements between a CGI nph-script (Non Parsed
Headers) and mod_perl with PerlSendHeaders Off.
In basic CGI, one can simply:
print "Content-Type: text/html\r\n\r\n";
When the CGI script goes back to the web server, it can see from this
output, destined for the client browser, that:
The request was successful
The content type is specified
There is nothing further special about this request.
On (one of) my machines this returns:
HTTP/1.1 200 OK
Connection: close
Date: Thu, 15 Mar 2001 19:09:23 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux) mod_perl/1.19
Content-Type: text/html
Client-Date: Thu, 15 Mar 2001 19:09:24 GMT
Client-Peer: xx.xx.xx.xx:80
This is actually pretty boring so far. I could send a cookie, too:
print "Set-Cookie: mycookie=test\r\n";
print "Content-Type: text/html\r\n\r\n";
Or any other headers I want, and the remainder is filled in by the webserver
for me.
But some magic happens when I want to, say, redirect. Instead of printing
my content-type header, all I have to do is print the following instead:
"Location: http://elsewhere.com\r\n\r\n";
Look what happens to the response!
HTTP/1.1 302 Found
Date: same
Server: same
Location: http://elsewhere.com
Connection: close
Content-Type: text/html
I have a different status line altogether (along with the Location: that I
printed)! One can arbitrarily send custom status codes, too... I've done
this with CGI form re-submits:
print "Status: 204 No Content\r\n\r\n";
This returns:
HTTP/1.1 204 No Content
Date: Thu, 15 Mar 2001 19:22:21 GMT
Server: Apache/1.3.3 (Unix) (Red Hat/Linux) mod_perl/1.19
Connection: close
Content-Type: text/plain
Which is an expensive NO-OP to a browser. No change in window content
WHATSOEVER. (I love that trick. Just love it! :-)
*NOW*
In mod_perl with PerlSendHeader Off, in order to perform a redirect one must
set up the headers manually:
Test.pm
===
package Test;
use Apache::Constants qw/:common REDIRECT/;
use strict;
sub handler() {
my $r = shift;
$r-content_type('text/html');
$r-headers_out-set(Location = "http://elsewhere.com");
return REDIRECT;
}
1;
REDIRECT here is a constant for the HTTP status code 302 (Moved).
But with PerlSendHeader On, I can take the same shortcuts as with CGI:
sub handler() {
print "Location: http://elsewhere.com\r\n\r\n";
}
And the response:
HTTP/1.1 302 Found
Date: Thu, 15 Mar 2001 19:32:10 GMT
Server: Apache/1.3.9 (Unix) (Red Hat/Linux) mod_perl/1.21
Location: http://elsewhere.com
Connection: close
Content-Type: text/plain
But THE *SAME* CODE with PerlSendHeader Off returns:
Location: http://elsewhere.com
And that's *IT*. Which parses as HTTP/0.9 and text/plain, causing my
browser to show that single line of text as my content.
NOW... to any non-newbies reading this, what have I left out? :-)
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Re: cgi_to_mod_perl manpage suggestion
- Original Message - From: "Perrin Harkins" [EMAIL PROTECTED] To: "Andrew Ho" [EMAIL PROTECTED] Cc: "Issac Goldstand" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 4:56 AM Subject: Re: cgi_to_mod_perl manpage suggestion On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. I recognize this confusion. Most recovering CGI programmers think that "PerlSendHeader On" means that you no longer have to do this in your CGI: print "Content-type: text/html\n\n"; When in fact you still do. The manpage makes it sound like you don't. Perhaps a note to that effect would be helpful. I certainly want newbies to understand the docs, but the man page does say very explicitly "Just as with mod_cgi, PerlSendHeader will not send the MIME type and a terminating double newline. Your script must send that itself..." Those were the lines that finally caused me to even try it the other way. But although they are there, they took me a long time to comprehend after the previous (and even possibly subsequent) misunderstandings. Issac
Re: cgi_to_mod_perl manpage suggestion
At 03:34 PM 03/14/01 +0200, Issac Goldstand wrote: On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Read it again. You are confusing "some" headers with "all" headers -- there's more than just Content-Type:. To me it doesn't sound at all like it will send content-type: PerlSendHeader On Now the response line and common headers will be sent as they are by mod_cgi. (response line and common headers != content type) And, just as with mod_cgi, PerlSendHeader will not send a terminating newline, your script must send that itself, e.g.: - print "Content-type: text/html\n\n"; All documentation has room for improvement, of course. It's confusing if you haven't written a mod_perl content handler before (or haven't read the perldoc Apache or the Eagle book) and don't know that you need $r-send_http_header under a normal content handler. And if you are like me, you have to read the docs a few times before it all makes sense. Also, note that Apache::Registry lets reasonably well written CGI scripts to run under both mod_cgi and Apache::Registry, which is what that man page is describing. It's not a CGI script if there's not a content-type: header sent. And the docs are not implying that you can turn on PerlSendHeader and then go through all your CGI scripts and remove the print "Content-type: text/html\n\n" lines. Bill Moseley mailto:[EMAIL PROTECTED]
Re: cgi_to_mod_perl manpage suggestion
- Original Message - From: "Bill Moseley" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 4:34 PM Subject: Re: cgi_to_mod_perl manpage suggestion At 03:34 PM 03/14/01 +0200, Issac Goldstand wrote: On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Read it again. You are confusing "some" headers with "all" headers -- there's more than just Content-Type:. To me it doesn't sound at all like it will send content-type: PerlSendHeader On Now the response line and common headers will be sent as they are by mod_cgi. (response line and common headers != content type) And, just as with mod_cgi, PerlSendHeader will not send a terminating newline, your script must send that itself, e.g.: - print "Content-type: text/html\n\n"; All documentation has room for improvement, of course. It's confusing if you haven't written a mod_perl content handler before (or haven't read the perldoc Apache or the Eagle book) and don't know that you need $r-send_http_header under a normal content handler. And if you are like me, you have to read the docs a few times before it all makes sense. Also, note that Apache::Registry lets reasonably well written CGI scripts to run under both mod_cgi and Apache::Registry, which is what that man page is describing. It's not a CGI script if there's not a content-type: header sent. And the docs are not implying that you can turn on PerlSendHeader and then go through all your CGI scripts and remove the print "Content-type: text/html\n\n" lines. Bill Moseley mailto:[EMAIL PROTECTED] So basically, PerlSendHeaders On means that it will send information such as the return code (eg HTTP/1.1 200 OK) ETag, Date and other headers that Apache generally handles on its own under mod_cgi? If so, then I think that all that really needs to be done is instead of giving a small lecture on PerlSendHeader which will be confusing to newbies, why not just write something basically telling them to set it to On and not worry. Remember that this is just the porting manpage, and if people really want to make their own handlers then they'll eventually learn the ins and outs of PerlSendHeader.
Re: cgi_to_mod_perl manpage suggestion
On Wed, 14 Mar 2001, Issac Goldstand wrote: So basically, PerlSendHeaders On means that it will send information such as the return code (eg HTTP/1.1 200 OK) ETag, Date and other headers that Apache generally handles on its own under mod_cgi? If so, then I think that all that really needs to be done is instead of giving a small lecture on PerlSendHeader which will be confusing to newbies, why not just write something basically telling them to set it to On and not worry. Remember that this is just the porting manpage, and if people really want to make their own handlers then they'll eventually learn the ins and outs of PerlSendHeader. This hopefully will give an indepth explanation of the behavior of this flag. May be too much :) http://thingy.kcilink.com/modperlguide/config/_Location_Configuration.html (scroll down to the PerlSendHeaders On part...) Notice, that the para says HTTP header, and it doesn't say anything about Content-type, which you always have to provide. Hmm, may be even that explanation can be improved. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cgi_to_mod_perl manpage suggestion
On Wed, 14 Mar 2001, Issac Goldstand wrote: I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Would it help if it said "PerlSendHeader On makes mod_perl act just like CGI with regard to headers"? - Perrin
Re: cgi_to_mod_perl manpage suggestion
Possibly. I think the idea is to keep in mind that people who are reading cgi_to_mod_perl are total newbies. Not only that, but many are planning on staying total newbies forever; they don't care about what mod_perl is actually for (or actually can do). I think that the cgi_to_mod_perl manpage should be targeted at that kind of perspective... Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "Perrin Harkins" [EMAIL PROTECTED] To: "Issac Goldstand" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 9:30 PM Subject: Re: cgi_to_mod_perl manpage suggestion On Wed, 14 Mar 2001, Issac Goldstand wrote: I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Would it help if it said "PerlSendHeader On makes mod_perl act just like CGI with regard to headers"? - Perrin
Re: cgi_to_mod_perl manpage suggestion
On Wed, 14 Mar 2001, Perrin Harkins wrote: On Wed, 14 Mar 2001, Issac Goldstand wrote: I still think that the above line is confusing: It is because mod_perl is not sending headers by itelf, but rather your script must provide the headers (to be returned by mod_perl). However, when you just say "mod_perl will send headers" it is misleading; it seems to indeicate that mod_perl will send "Content-Type: text/html\r\n\r\n" all by itself, and that conversely, to disable that PerlSendHeaders should be Off. Would it help if it said "PerlSendHeader On makes mod_perl act just like CGI with regard to headers"? A small correction: "PerlSendHeader On makes mod_perl act just like mod_cgi with regard to HTTP headers" :) CGI is a protocol... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cgi_to_mod_perl manpage suggestion
Hello, SBA small correction: "PerlSendHeader On makes mod_perl act just like SBmod_cgi with regard to HTTP headers" :) +1 vote for adding this simple sentence, which IMO would clear up lots of CGI to mod_perl beginner confusion. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: cgi_to_mod_perl manpage suggestion
Personally I'll admit that I've gotten screwed by this before... I usually remember that it's a setting and set it one way, and then when my script doesnt work, I set it the other way. Of course I didnt read the docs thoroughly, but because it was confusing, I just try it until it worked. Maybe other people aren't as patient. I would be all for the clear explanation. At 08:28 PM 3/14/2001 -0800, Andrew Ho wrote: Hello, SBA small correction: "PerlSendHeader On makes mod_perl act just like SBmod_cgi with regard to HTTP headers" :) +1 vote for adding this simple sentence, which IMO would clear up lots of CGI to mod_perl beginner confusion. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: cgi_to_mod_perl manpage suggestion
On Tue, 13 Mar 2001, Issac Goldstand wrote: The only problem was the PerlSendHeaders option. The first fifty or so times that I read the manpages, I understood that PerlSendHeader On means that mod_perl will SEND HEADERS, and that off meant supply your own... Somehow I figured out (eventually) that this was not so, switched all of my deliberately placed PerlSendHeader Off statesments to a single On statement, and all of my scripts once again work. Um, you're getting me confused now, but PerlSendHeader On means that mod_perl WILL send headers. I think the main problem was the line : By default, mod_perl does not send any headers by itself, however, you may wish to change this: PerlSendHeader On That seems to say that if you want mod_perl to handle headers for you, cange it to On. That's correct. - Perrin
Re: cgi_to_mod_perl manpage suggestion
Hello, PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I recognize this confusion. Most recovering CGI programmers think that "PerlSendHeader On" means that you no longer have to do this in your CGI: print "Content-type: text/html\n\n"; When in fact you still do. The manpage makes it sound like you don't. Perhaps a note to that effect would be helpful. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: cgi_to_mod_perl manpage suggestion
On Tue, 13 Mar 2001, Andrew Ho wrote: PHUm, you're getting me confused now, but PerlSendHeader On means that PHmod_perl WILL send headers. I recognize this confusion. Most recovering CGI programmers think that "PerlSendHeader On" means that you no longer have to do this in your CGI: print "Content-type: text/html\n\n"; When in fact you still do. The manpage makes it sound like you don't. Perhaps a note to that effect would be helpful. I certainly want newbies to understand the docs, but the man page does say very explicitly "Just as with mod_cgi, PerlSendHeader will not send the MIME type and a terminating double newline. Your script must send that itself..." - Perrin
