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

Re: [MacPerl] Odd behavior on die()



Doug Roberts (inbox@headspace.com) writes:
}Hi All -
}
}I get two odd behaviors using the following code:
}
}sub openFile
}{
}	unless(open(HTTP_LOG, "access2-14.txt"))
}	{
}	print <<"END_TAG";
}	<HTML> <HEAD> <TITLE> CGI Error </TITLE> </HEAD>
}	<BODY  TEXT='#000000' LINK='#0000FF' VLINK='#AA1177' ALINK='#00BB00'
}BGCOLOR='#FFFFFF'>
}	<CENTER><H2> If this failed, its no damn surprise </H2>
}	<B>The file you requested could not be opened for one reason or
}another.</B><br><BR>
}	If this is a real problem, let <A
}HREF='mailto:inbox\@headspace.com'>Doug</A> know</CENTER><HR>
}	</BODY>
}	</HTML>
}END_TAG
}die("\n");
}	}
}}
}
}First, die() prints a line with a # using MacPerl, but not Perl 5 under

Yes, I've noticed that, too.  I had to change a line in libwww-perl-5 that
was looking for /^Can't/ to /Can't/  because of this.

}Win NT (which is where this CGI is running). So if I use "Die("Error!);
}the actual output is "# Error!" I guess this is just inconsistant, but I
}may be doing something wrong. It's bothersome for outputting clean HTML.
}
}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.  Now I believe I read on this list at one time that the MacPerl
CGI glue *might* (I've never used it, so take this for what it's worth) try
to fix end-of-line, but I'm certainly not sure.  I've never used that
bastard child of VMS, WinNT (VMS was bad enough), but I've no doubt \n
means something different there than it does on a Mac.  So you might try
portably terminating your Content-type: line and see if that fixes your
problem.

}fails, the page just spews out - so if I included the previous line, it
}would be the first line of the output page in Netscape. Delete the line
}and everything works fine. The code to output the "real" page (not
}generated by an error handler) requires the line "Content-type:
}text/html\n\n" or a server error occurs. The server is Netscape
}FastTrack under WinNT
}
}Can anyone shed some light on whether this is expected behavior that I
}haven't bothered to look up?
}
}Thanks
}Doug Roberts
}inbox@headspace.com


---
Paul J. Schinder
NASA Goddard Space Flight Center
Code 693, Greenbelt, MD 20771
schinder@pjstoaster.pg.md.us