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
