perl vs C for CGI

Discussion in 'Perl Misc' started by saran.jegan@gmail.com, Jun 12, 2007.

  1. Guest

    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
     
    , Jun 12, 2007
    #1
    1. Advertising

  2. Ian Wilson Guest

    wrote:
    > 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.


    >
    > server:apache
    >
     
    Ian Wilson, Jun 12, 2007
    #2
    1. Advertising

  3. On 2007-06-12 13:09, Petr Vileta <> wrote:
    > 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)

    > 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

    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Jun 13, 2007
    #3
  4. On 2007-06-13 10:49, Petr Vileta <> wrote:
    > Peter J. Holzer wrote:
    >> On 2007-06-12 13:09, Petr Vileta <> wrote:
    >>> 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


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Jun 13, 2007
    #4
  5. Guest

    On Jun 14, 6:22 am, "Petr Vileta" <> wrote:
    > Peter J. Holzer wrote:
    > > On 2007-06-13 10:49, Petr Vileta <> wrote:
    > >> 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.

    >
    > 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
     
    , Jun 14, 2007
    #5
  6. On Wed, 13 Jun 2007 14:35:50 +0200, "Peter J. Holzer"
    <> wrote:

    >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
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, Jun 14, 2007
    #6
  7. On 2007-06-14 17:11, Michele Dondi <> wrote:
    > On Wed, 13 Jun 2007 14:35:50 +0200, "Peter J. Holzer"
    ><> wrote:
    >>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.


    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

    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Jun 15, 2007
    #7
  8. Dr.Ruud Guest

    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.

    --
    Affijn, Ruud

    "Gewoon is een tijger."
     
    Dr.Ruud, Jun 15, 2007
    #8
  9. Peter J. Holzer <> wrote:
    > On 2007-06-14 17:11, Michele Dondi <> wrote:
    >> On Wed, 13 Jun 2007 14:35:50 +0200, "Peter J. Holzer"
    >><> wrote:
    >>>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.

    >
    > 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.


    --
    Tad McClellan
    email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
     
    Tad McClellan, Jun 16, 2007
    #9
  10. On 2007-06-15 20:36, Dr.Ruud <> wrote:
    > 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.


    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

    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Jun 16, 2007
    #10
  11. On 2007-06-15 23:31, Tad McClellan <> wrote:
    > Peter J. Holzer <> wrote:
    >> On 2007-06-14 17:11, Michele Dondi <> wrote:
    >>> On Wed, 13 Jun 2007 14:35:50 +0200, "Peter J. Holzer"
    >>><> wrote:
    >>>>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.

    >>
    >> To my surprise they are portable at least between Unix and Windows. Perl
    >> seems to automatically detect the line endings


    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.


    >> 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".


    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


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Jun 16, 2007
    #11
  12. On Fri, 15 Jun 2007 22:36:09 +0200, "Dr.Ruud"
    <> wrote:

    >> 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,


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


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, Jun 16, 2007
    #12
  13. Dr.Ruud Guest

    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.

    --
    Affijn, Ruud

    "Gewoon is een tijger."
     
    Dr.Ruud, Jun 16, 2007
    #13
  14. On 2007-06-16 14:21, Dr.Ruud <> wrote:
    > 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.


    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


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Jun 16, 2007
    #14
  15. Dr.Ruud Guest

    Peter J. Holzer schreef:
    > Dr.Ruud:
    >> Peter J. Holzer:


    >>> 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.

    >
    > 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.

    --
    Affijn, Ruud

    "Gewoon is een tijger."
     
    Dr.Ruud, Jun 16, 2007
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jürgen Exner

    Re: CGI Perl "use CGI" statement fail

    Jürgen Exner, Jul 31, 2003, in forum: Perl
    Replies:
    0
    Views:
    1,428
    Jürgen Exner
    Jul 31, 2003
  2. praba kar

    Python-cgi or Perl-cgi script doubt

    praba kar, Jul 30, 2005, in forum: Python
    Replies:
    1
    Views:
    644
    Michael Sparks
    Jul 30, 2005
  3. excord80
    Replies:
    17
    Views:
    697
    J Kenneth King
    Jan 29, 2009
  4. shumsta
    Replies:
    1
    Views:
    274
    Fabian Pilkowski
    Jul 22, 2005
  5. kath
    Replies:
    4
    Views:
    652
    J. Gleixner
    Apr 9, 2007
Loading...

Share This Page