[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Odd behavior on die()



Re Paul Schinder's reply to Doug Roberts:

>}Secondly, you may notice that this print routine is missing the
>}"Content-type: text/html\n\n" line. It seems that if the file open
>
>Alarm bells just went off.  HTTP requires a certain line end for
>Content-type:.  I don't remember exactly what it is, but it's either
>\012\012 or \015\012\015\012.  Note that you cannot *portably* write these
>any other way in Perl, no combination of \r and \n will be correct on all
>platforms.

The book "HTML & CGI Unleashed" emphasizes that all CGI scripts 
should ensure that the two bytes following the last printable byte of
a "Content-type..." line are \012\012 to ensure compatibility.  The
authors seem to assume that Perl is always running on Unix and they use
\n\n to end this kind of line in all Perl script examples. But, when
discussing C language CGIs they recommend the following for portability:

    printf( "Content-type: text/html%c%c", 10 10 );

Certainly it would seem just as good to use the C statement:

    printf( "Content-type: text/html\012\012" );  /* or */
    printf( "Content-type: text/html\x10\x10" );

As expected, the MacPerl program
    printf "octal charcode %03o\n", ord( "\n" );
prints
    octal charcode 015
which is consistent with both the definition of \n on a Mac, and the
hypothesis that this may cause problems.

So, I think I will change all of my CGI scripts to:

    print "Content-type: text/html\012\012";

However I have scripts that use \n that have been working OK, so far
as I know, for many months on both a Unix server (no surprise) and
my MacHTTP server running MacPerl CGIs (hmmm) ... so maybe this doesn't
bite unless you get an unlucky (older?) combination of server, script,
or browser.

    -Paul-      paul.b.patton@hbc.honeywell.com