perl vs C for CGI

S

saran.jegan

Hello,
am having a program in C which throws "internal server error"
reason is premature end of script headers but i checked my http header
& syntax of the program too , its fine. but when am re-program the
same in perl it works fine
i need to know the reason for the problem with C ,do any memory
problem cause this error ,can any suggest me on this.thanks for your
time


server:apache
 
I

Ian Wilson

Hello,
am having a program in C which throws "internal server error"
reason is premature end of script headers but i checked my http header
& syntax of the program too , its fine.

If Apache says your C program suffers froma premature end of script
headers I'd believe it. Probably you are not properly separating headers
from content or are not emitting headers.

You might like to re-read the CGI specs and see what they say about line
terminators and separating HTTP headers from the content.
but when am re-program the
same in perl it works fine

I'd run both programs from the command line, redirect output to files
and diff the files.
i need to know the reason for the problem with C ,do any memory
problem cause this error ,can any suggest me on this.thanks for your
time

It's not a Perl problem so its not appropriate to a Perl newsgroup, I'd
try writing a "hello world" CGI program in C and if I got the same
errors, include the C source in a posting to a C newsgroup

It may be that you misunderstand CGI in which case asking in a CGI
newsgroup would be appropriate.
 
P

Peter J. Holzer

am having a program in C which throws "internal server error"
reason is premature end of script headers but i checked my http header
& syntax of the program too , its fine. but when am re-program the
same in perl it works fine [...]
server:apache
You did not mentioned about operating systems ;-) On Unix/Linux the end of
line is 0x0d (one byte)

Nope. It's 0x0A. (It was 0x0D on MacOS <= 9)
but on Windows this is 0x0d, 0x0a.
Perl put right EndOfLine character(s) by the operating system where is
running but C source code must be compiled to executable.

AFAIK Apache accepts both LF and CRLF from CGI scripts.

hp
 
P

Peter J. Holzer

Peter said:
(e-mail address removed) wrote:
am having a program in C which throws "internal server error"
reason is premature end of script headers but i checked my http
header & syntax of the program too , its fine. but when am
re-program the same in perl it works fine [...]
server:apache
You did not mentioned about operating systems ;-) On Unix/Linux the
end of line is 0x0d (one byte)

Nope. It's 0x0A. (It was 0x0D on MacOS <= 9)
Right, II had some obfuscations in my head at deep night ;-)
AFAIK Apache accepts both LF and CRLF from CGI scripts.
Maybe Apache 2.x, I don't know, but Apache 1.2 have problem with windows
like end-of-line. I have this on my Linux server and anytime I forget to
convert cgi file to unix format I get the same error message.

If you don't convert the *script* (as opposed to print statements within
the script), apache probably can't even start the script because the
linux kernel will try to invoke "/usr/bin/perl\r" which doesn't exist.
You can test this by running the script from the command line.
Since a script which doesn't run can't produce any headers, you'll get
the "premature end of script headers" error. But the problem is that
there are no headers at all not that they have the wrong line endings.

hp
 
S

saran.jegan

I have my Apache setting for not send any (automatic) headers and I assume
that in this setting Apache get system error message and send "premature end
of script headers" to the browser. I'm not system analyst ;-)
--

Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)

hello dudes,

Finally whats your point , do apache have some system specific
problems with windows, since my code is 100% ok ( since its running
well in linux ). am spending nearly a week in this , thanks for your
time
 
M

Michele Dondi

If you don't convert the *script* (as opposed to print statements within
the script), apache probably can't even start the script because the
linux kernel will try to invoke "/usr/bin/perl\r" which doesn't exist.

BTW: I've always wondered... how 'bout HERE docs? Are they portable
across platforms or is the line ending deemed to be that of the
script. Is the question clear enough, BTW?


Michele
 
P

Peter J. Holzer

BTW: I've always wondered... how 'bout HERE docs? Are they portable
across platforms or is the line ending deemed to be that of the
script.

To my surprise they are portable at least between Unix and Windows. Perl
seems to automatically detect the line endings and convert them to
\x{0A} at compile time. A string written as a here document always
contains simple "\n" characters as line endings regardless of whether
the source file contained CRLFs or LF and whether it's executed on
Windows or Unix.

hp
 
D

Dr.Ruud

Peter J. Holzer schreef:
A string written as a here document always
contains simple "\n" characters as line endings regardless of whether
the source file contained CRLFs or LF and whether it's executed on
Windows or Unix.


And so it should. That \n is a metacharacter (line separator) that,
depending on platform and binmode, can become CR+LF again when written
out.
 
T

Tad McClellan

Peter J. Holzer said:
To my surprise they are portable at least between Unix and Windows. Perl
seems to automatically detect the line endings and convert them to
\x{0A} at compile time. A string written as a here document always
contains simple "\n" characters as line endings regardless of whether
the source file contained CRLFs or LF and whether it's executed on
Windows or Unix.


See the "PERLIO" section in perlrun.pod:

On Win32 the default in this release is "unix crlf". Win32's "stdio"
has a number of bugs/mis-features for perl IO which are somewhat
C compiler vendor/version dependent. Using our own C<crlf> layer as
the buffer avoids those issues and makes things more uniform.
The C<crlf> layer provides CRLF to/from "\n" conversion as well as
buffering.
 
P

Peter J. Holzer

Peter J. Holzer schreef:


And so it should.

I concede that may sometimes be convenient. I'm less convinced that it
*should* do that. On unix, line endings are indicated by a single byte
0x0A. There is little reason to expect that the sequence of bytes

0000000 $ s = < < E O S ; \r \n L i n
0000020 e 1 \r \n L i n e 2 \r \n E O S
0000040 \r \n

in the *source code* of a script should be parsed into

$s = "Line 1\nLine 2\n";

on Unix. Why are the \r characters suppressed? Perl doesn't suppress
other control characters in string literals.
That \n is a metacharacter (line separator) that,
depending on platform and binmode, can become CR+LF again when written
out.

Right. But it it does that regardless of platform (and of course
binmode) while compiling the script. So on Unix, if you explicitely
include literal CRLFs in your string literals (which you shouldn't,
imho), they are silently converted to LFs.

hp
 
P

Peter J. Holzer

No, I was mistaken. It doesn't detect anything, it just ignores CR if it
is immediately followed by LF. So you can have a script where some lines
are terminated by LF and some by CRLF and perl won't care.

See the "PERLIO" section in perlrun.pod:

On Win32 the default in this release is "unix crlf".

I wasn't surprised about the way perl works on windows, I was surprised
about how it works on Unix. And I was talking about the way perl is
reading/parsing source code, not about any I/O a script performs. (The
implicit crlf layer for reading source has existed long before the IO
layers: I've tested that with perl 5.005_03 on Linux).

hp
 
M

Michele Dondi

And so it should. That \n is a metacharacter (line separator) that,

When he wrote "To my surprise" I suppose he meant "to my *pleasant*
surprise".


Michele
 
D

Dr.Ruud

Peter J. Holzer schreef:
So on Unix, if you explicitely
include literal CRLFs in your string literals (which you shouldn't,
imho), they are silently converted to LFs.

How do you mean?

$ perl -wle'
print length <<"EOS";
abc\r
def\r
EOS
'

This prints 10, so not 8.
 
P

Peter J. Holzer

Peter J. Holzer schreef:

How do you mean?

$ perl -wle'
print length <<"EOS";
abc\r
def\r
EOS
'

This prints 10, so not 8.

Not if the "\r" in your code above are actual CR characters (instead of
a backslash followed by an r):

hrunkner:~ 19:20 104% perl -wle'
quote> print length <<EOS;
quote> abc^M
quote> def
quote> EOS
quote> '
8
hrunkner:~ 19:25 105% perl -wle'
print length <<EOS;
abc^K
def
EOS
'
9

perl -wle'
print length <<EOS;
abc^M^M
def
EOS
'
9

hp
 
D

Dr.Ruud

Peter J. Holzer schreef:
Dr.Ruud:

Not if the "\r" in your code above are actual CR characters (instead
of a backslash followed by an r):

% perl -wle'
print length <<EOS;
abc^M
def
EOS
'
8

Ah, that is scary indeed. Interpolation is not a factor:

$ perl -wle'
print length <<'EOS';
abc^M
def
EOS
'
8

$ perl -wle'
print length <<"EOS";
abc^M\ndef
EOS
'
9

It smells like (having been once) a bug to me.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top