Re: Support of CR LF in a EBCDIC environment
Dear list readers - I'm working with the following environment: BS2000-Posix as O.S. Perl-5.005_54 Apache-1.3.9 Mod_perl-1.21 BS2000-Posix has the EBCDIC as character set, both Apache-1.3.9 and perl-5.005_54 are ported to support EBCDIC code. I installed Apache with mod_perl and tried the counter example of the mod_perl guide: This example would work only if you have PerlSendHeader set to 'On' in the config file. Is it On? May be this is not a problem "\r\n", if this is your case Generally "\n\n" is enough for most (all?) of the widely used browsers (clients), but to be complient with HTTP RFCs one has to use "\r\n\r\n". what do you get when you replace this mod_cgi'ish header sending with true mod_perl'ish: my $r = shift; $r-content_type('text/html'); $r-send_http_header; or simpler: my $r = shift; $r-send_http_header('text/html'); Does it work? #!/usr/local/bin/perl -w use strict; print "Content-type: text/html\r\n\r\n"; my $counter = 0; for (1..5) { increment_counter(); } sub increment_counter{ $counter++; print "Counter is equal to . $counter !BR\n"; } The result that I have is: HTTP/1.1 200 OK Date: Mon, 15 Nov 1999 09:36:57 GMT Server: Apache/1.3.9 (BS2000) mod_perl/1.21 ApacheJServ/1.0 Connection: close Content-Type: text/plain Counter is equal to . 1 !BR Counter is equal to . 2 !BR Counter is equal to . 3 !BR Counter is equal to . 4 !BR Counter is equal to . 5 !BR Connection closed by foreign host. The content-type is text/plain instead text/html, mod_perl loses this header probably due to EBCDIC conversion of the "\n" character. Trying with print "Content-type: text/html\r\n"; or with print "Content-type: text/html\r\r\n"; the content-type is text/html, as it should be. I looked the sources of mod_perl for some part where the mod_perl is preparing the headers from the output of perl5 and to pass them to the apache. I don't understand who is doing that. Can someone help me to find where the content-type header is lost. -- Ignasi Roca ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
RE: Support of CR LF in a EBCDIC environment
I'm not familiar with EBCDIC, but in Perl \r and \n are platform dependent, you migh want to try the platform independent \015 (cr) and \012 (lf). [EMAIL PROTECTED] wrote: Dear list readers - I'm working with the following environment: BS2000-Posix as O.S. Perl-5.005_54 Apache-1.3.9 Mod_perl-1.21 BS2000-Posix has the EBCDIC as character set, both Apache-1.3.9 and perl-5.005_54 are ported to support EBCDIC code. I installed Apache with mod_perl and tried the counter example of the mod_perl guide: #!/usr/local/bin/perl -w use strict; print "Content-type: text/html\r\n\r\n"; my $counter = 0; for (1..5) { increment_counter(); } sub increment_counter{ $counter++; print "Counter is equal to . $counter !BR\n"; } The result that I have is: HTTP/1.1 200 OK Date: Mon, 15 Nov 1999 09:36:57 GMT Server: Apache/1.3.9 (BS2000) mod_perl/1.21 ApacheJServ/1.0 Connection: close Content-Type: text/plain Counter is equal to . 1 !BR Counter is equal to . 2 !BR Counter is equal to . 3 !BR Counter is equal to . 4 !BR Counter is equal to . 5 !BR Connection closed by foreign host. The content-type is text/plain instead text/html, mod_perl loses this header probably due to EBCDIC conversion of the "\n" character. Trying with print "Content-type: text/html\r\n"; or with print "Content-type: text/html\r\r\n"; the content-type is text/html, as it should be. I looked the sources of mod_perl for some part where the mod_perl is preparing the headers from the output of perl5 and to pass them to the apache. I don't understand who is doing that. Can someone help me to find where the content-type header is lost. -- Ignasi Roca
RE: Support of CR LF in a EBCDIC environment
Your proposal works. Then, how to solve "the problem with "\n\n" ? To be compatible It should also work. This example would work only if you have PerlSendHeader set to 'On' in the config file. Is it On? May be this is not a problem "\r\n", if this is your case Generally "\n\n" is enough for most (all?) of the widely used browsers (clients), but to be complient with HTTP RFCs one has to use "\r\n\r\n". what do you get when you replace this mod_cgi'ish header sending with true mod_perl'ish: my $r = shift; $r-content_type('text/html'); $r-send_http_header; or simpler: my $r = shift; $r-send_http_header('text/html'); Does it work? #!/usr/local/bin/perl -w use strict; print "Content-type: text/html\r\n\r\n"; my $counter = 0; for (1..5) { increment_counter(); } sub increment_counter{ $counter++; print "Counter is equal to . $counter !BR\n"; } The result that I have is: HTTP/1.1 200 OK Date: Mon, 15 Nov 1999 09:36:57 GMT Server: Apache/1.3.9 (BS2000) mod_perl/1.21 ApacheJServ/1.0 Connection: close Content-Type: text/plain Counter is equal to . 1 !BR Counter is equal to . 2 !BR Counter is equal to . 3 !BR Counter is equal to . 4 !BR Counter is equal to . 5 !BR Connection closed by foreign host. The content-type is text/plain instead text/html, mod_perl loses this header probably due to EBCDIC conversion of the "\n" character. Trying with print "Content-type: text/html\r\n"; or with print "Content-type: text/html\r\r\n"; the content-type is text/html, as it should be. I looked the sources of mod_perl for some part where the mod_perl is preparing the headers from the output of perl5 and to pass them to the apache. I don't understand who is doing that. Can someone help me to find where the content-type header is lost. -- Ignasi Roca ___ Stas Bekman mailto:[EMAIL PROTECTED] www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheaven http://www.singlesheaven.com
RE: Support of CR LF in a EBCDIC environment
Your proposal works. which one did work for you: PerlSendHeader On or $r-send_http_header? Then, how to solve "the problem with "\n\n" ? To be compatible It should also work. This example would work only if you have PerlSendHeader set to 'On' in the config file. Is it On? May be this is not a problem "\r\n", if this is your case Generally "\n\n" is enough for most (all?) of the widely used browsers (clients), but to be complient with HTTP RFCs one has to use "\r\n\r\n". what do you get when you replace this mod_cgi'ish header sending with true mod_perl'ish: my $r = shift; $r-content_type('text/html'); $r-send_http_header; or simpler: my $r = shift; $r-send_http_header('text/html'); Does it work? #!/usr/local/bin/perl -w use strict; print "Content-type: text/html\r\n\r\n"; my $counter = 0; for (1..5) { increment_counter(); } sub increment_counter{ $counter++; print "Counter is equal to . $counter !BR\n"; } The result that I have is: HTTP/1.1 200 OK Date: Mon, 15 Nov 1999 09:36:57 GMT Server: Apache/1.3.9 (BS2000) mod_perl/1.21 ApacheJServ/1.0 Connection: close Content-Type: text/plain Counter is equal to . 1 !BR Counter is equal to . 2 !BR Counter is equal to . 3 !BR Counter is equal to . 4 !BR Counter is equal to . 5 !BR Connection closed by foreign host. The content-type is text/plain instead text/html, mod_perl loses this header probably due to EBCDIC conversion of the "\n" character. Trying with print "Content-type: text/html\r\n"; or with print "Content-type: text/html\r\r\n"; the content-type is text/html, as it should be. I looked the sources of mod_perl for some part where the mod_perl is preparing the headers from the output of perl5 and to pass them to the apache. I don't understand who is doing that. Can someone help me to find where the content-type header is lost. -- Ignasi Roca ___ Stas Bekman mailto:[EMAIL PROTECTED] www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheaven http://www.singlesheaven.com ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
RE: Support of CR LF in a EBCDIC environment
Your proposal works. which one did work for you: PerlSendHeader On or $r-send_http_header? In my first try with the print "Content-type: text/html\r\n\r\n" I had the "PerlSendHeader On" and the content-type of the response was "text/plain". In the second try with "$r-send_http_header" I removed the "PerlSendHeader On" and the content-type of the response is "text/html" Then, how to solve "the problem with "\n\n" ? To be compatible It should also work. This example would work only if you have PerlSendHeader set to 'On' in the config file. Is it On? May be this is not a problem "\r\n", if this is your case Generally "\n\n" is enough for most (all?) of the widely used browsers (clients), but to be complient with HTTP RFCs one has to use "\r\n\r\n". what do you get when you replace this mod_cgi'ish header sending with true mod_perl'ish: my $r = shift; $r-content_type('text/html'); $r-send_http_header; or simpler: my $r = shift; $r-send_http_header('text/html'); Does it work? #!/usr/local/bin/perl -w use strict; print "Content-type: text/html\r\n\r\n"; my $counter = 0; for (1..5) { increment_counter(); } sub increment_counter{ $counter++; print "Counter is equal to . $counter !BR\n"; } The result that I have is: HTTP/1.1 200 OK Date: Mon, 15 Nov 1999 09:36:57 GMT Server: Apache/1.3.9 (BS2000) mod_perl/1.21 ApacheJServ/1.0 Connection: close Content-Type: text/plain Counter is equal to . 1 !BR Counter is equal to . 2 !BR Counter is equal to . 3 !BR Counter is equal to . 4 !BR Counter is equal to . 5 !BR Connection closed by foreign host. The content-type is text/plain instead text/html, mod_perl loses this header probably due to EBCDIC conversion of the "\n" character. Trying with print "Content-type: text/html\r\n"; or with print "Content-type: text/html\r\r\n"; the content-type is text/html, as it should be. I looked the sources of mod_perl for some part where the mod_perl is preparing the headers from the output of perl5 and to pass them to the apache. I don't understand who is doing that. Can someone help me to find where the content-type header is lost. -- Ignasi Roca ___ Stas Bekman mailto:[EMAIL PROTECTED] www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheaven http://www.singlesheaven.com ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
RE: Support of CR LF in a EBCDIC environment
which one did work for you: PerlSendHeader On or $r-send_http_header? In my first try with the print "Content-type: text/html\r\n\r\n" I had the "PerlSendHeader On" and the content-type of the response was "text/plain". In the second try with "$r-send_http_header" I removed the "PerlSendHeader On" and the content-type of the response is "text/html" Which means that the problem lies in parsing the possible header from the scripts when "PerlSendHeader On", otherwise you don't have any problem with EBCDIC environment, as $r-send_http_header sends it correctly... Then, how to solve "the problem with "\n\n" ? To be compatible It should also work. This example would work only if you have PerlSendHeader set to 'On' in the config file. Is it On? May be this is not a problem "\r\n", if this is your case Generally "\n\n" is enough for most (all?) of the widely used browsers (clients), but to be complient with HTTP RFCs one has to use "\r\n\r\n". what do you get when you replace this mod_cgi'ish header sending with true mod_perl'ish: my $r = shift; $r-content_type('text/html'); $r-send_http_header; or simpler: my $r = shift; $r-send_http_header('text/html'); Does it work? #!/usr/local/bin/perl -w use strict; print "Content-type: text/html\r\n\r\n"; my $counter = 0; for (1..5) { increment_counter(); } sub increment_counter{ $counter++; print "Counter is equal to . $counter !BR\n"; } The result that I have is: HTTP/1.1 200 OK Date: Mon, 15 Nov 1999 09:36:57 GMT Server: Apache/1.3.9 (BS2000) mod_perl/1.21 ApacheJServ/1.0 Connection: close Content-Type: text/plain Counter is equal to . 1 !BR Counter is equal to . 2 !BR Counter is equal to . 3 !BR Counter is equal to . 4 !BR Counter is equal to . 5 !BR Connection closed by foreign host. The content-type is text/plain instead text/html, mod_perl loses this header probably due to EBCDIC conversion of the "\n" character. Trying with print "Content-type: text/html\r\n"; or with print "Content-type: text/html\r\r\n"; the content-type is text/html, as it should be. I looked the sources of mod_perl for some part where the mod_perl is preparing the headers from the output of perl5 and to pass them to the apache. I don't understand who is doing that. Can someone help me to find where the content-type header is lost. -- Ignasi Roca ___ Stas Bekman mailto:[EMAIL PROTECTED] www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheaven http://www.singlesheaven.com ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com