Frontpage, CGI, perl and uploading

[Richard Bell]

I'm new to FrontPage and have encountered a rather strange problem I
don't understand. Here are the symptoms:

I've created a simple page (has a form with a submit button whose
action points to /cgi/test.cgi).

/cgi/test.cgi is a perl script that simply writes a trivial web page (
"hi dude").

I publish the page and cgi

When I click on the submit button I get a server 500 error

Now here is where it gets strange ... if I open the published
/cgi/test.cgi file on the server and then save it (no edits made) and
try the submit button again all is well!

I recall from some years back that there is a difference in Windows
and Unix flavors about the last character in the file (a 0x00 if I
recall). I'm just guessing that by opening and then closing the the
/cgi/test.cgi file I'm 'Unixifing' the /cgi/test.cgi file so now
things work. The question is what do I do on the FrontPage side to
tell it that it's publishing to a Unix system so that it publishes
Unix compatible files?

Thanks.

 

[Richard Bell]

I should have also mentioned that the problem only occurs when I
publish with FrontPage services (the Unix server has the extensions
installed) but does not occur when I use FrontPage FTP !!??

Anyone have any clues as to what is going on?

 

[Andrew Murray]

cgi scripts don't need frontpage extensions, but you do need to publish via FP
http: to the cgi-bin so as not to break the extensions if the rest of your site
uses them.

 

[Andrew Murray]

You need to set the file permissions (are you on a Unix server or Windows?)

i on Windows, I expect you need to have the perl interpreter running on Windows,
if it is unix, you need to set the file permissions, the common one is chmod 755.

Remember open perl scripts in Notepad only (or other pure ascii text editor - FP
editor is not suitable for this) not in Wordpad, else you'll screw up the
text-only format.

Publishing cgi files by FTP is probably the best way, but you risk messing up the
FP extensions if so.

 

[Ronx]

This applies to Unix Servers:

On both the server and your local copy of the web convert the cgi folder to
subwebs. This allows the safe use of FTP. Never open the cgi folders in
FrontPage again.

Perl/cgi scripts should be uploaded with a third party FTP client, such as
cuteFTP, WSFTP etc. Set the client to treat the script files as ASCII text,
not as binaries. Note that FrontPage will always treat .cgi, .pl and .pm
files as binaries (FP2003 can be set to use ASCII on these extensions, but
it is a manual setting - Tools->Options->FTP tag and add the appropriate
extensions).

When the files are uploaded, use the CHMOD function in the FTP client to
check the attributes on each file are set to 755:
Owner Read Write Execute
Group Read Execute
Others Read Execute

Some servers do not need the CHMOD operation, but most do.

The major difference between Unix and Windows text files is the EOL
character -
Windows uses the combination CRLF, whereas UNIX uses the single character LF
(I think).
The extra CR in a Windows file "confuses" the Perl interpreter, and causes
errors.

 

[Richard Bell]

Thanks for the feedback.

FYI, on my copy of FP 2003 CGI is defaulted to ASCII. Additionally,
I'm able to FTP the CGI directory to the Unix server without any
apparent issue (at least so far) save for the EOL nonsense. Also,
happily, once the permissions are properly set on the Unix side, FP
leaves them alone during a publish.

Regarding permissions, I noticed that there is a "allow scripts or
programs to be run" check box on the properties for directories. I
also bumped across some MS knowledge base entries to the effect that
FP treats CGI-BIN 'special' and sets the execute bit. On my FP the
'allow' is gray and can not be selected. Additionally the Unix server
I'm using stores cgi in CGI not CGI-BIN. Are you aware of any way of
dealing with this?

A bit of investigation verified what you said about the EOL issue.
Using CuteFTP to 'edit' the cgi file without actually changing
anything and then saving it apparently rewrites the lines correctly
(file size on the Unix side remains constant). Interestingly, using
Cute FTP to retrieve the cgi file converts it back to a windows format
(file size increases with the addition of one CR for each line).
Conversely, using a web folder from explorer brings back the real
bytes (Windows file size matches Unix size)! Go figure. In any case,
using explorer to actually retrieve the real bytes from the Unix side
and then examining the files clearly reveals the issue with CR.

I assume from your rather complete comments (thanks, by the way) that
there is no way to configure FP to publish in Unix file format. More
than a bit of a downer that. If there is, I'd like to know as I'm
otherwise relatively happy with FP.

Finally, are you aware of any cgi/pl/php addins for FP that will
improve its ability to deal with this?

Thanks again.

 

[Ronx]

Comments Inline

--
Ron Symonds (Microsoft MVP - FrontPage)
Reply only to group - emails will be deleted unread.

Thanks for the feedback.

FYI, on my copy of FP 2003 CGI is defaulted to ASCII. Additionally,
I'm able to FTP the CGI directory to the Unix server without any
apparent issue (at least so far) save for the EOL nonsense. Also,
happily, once the permissions are properly set on the Unix side, FP
leaves them alone during a publish.

I tend to worry (so far, needlessly) about FrontPage and permissions, hence
the subweb. The subweb also protects the rest of the website against errors
when using FTP - the errors WILL happen, no matter how careful you are.
FP2003 will correctly FTP a Perl script to a Unix server (if the extension
is set as ASCII), but I have never tried the HTTP publish (and never will -
if it isn't broke, don't fix it).

My own FTP client also leaves the permissions alone, once set.

Regarding permissions, I noticed that there is a "allow scripts or
programs to be run" check box on the properties for directories. I
also bumped across some MS knowledge base entries to the effect that
FP treats CGI-BIN 'special' and sets the execute bit. On my FP the
'allow' is gray and can not be selected. Additionally the Unix server
I'm using stores cgi in CGI not CGI-BIN. Are you aware of any way of
dealing with this?

The folder(s) to be used for Perl/CGI scripts in Unix is set in the server
configuration files. I have never noticed any difference in the way FP
treats the cgi-bin folder on Windows servers, but then, Windows is not Unix.
I only go near the cgi-bin on Unix with an FTP client.

A bit of investigation verified what you said about the EOL issue.
Using CuteFTP to 'edit' the cgi file without actually changing
anything and then saving it apparently rewrites the lines correctly
(file size on the Unix side remains constant). Interestingly, using
Cute FTP to retrieve the cgi file converts it back to a windows format
(file size increases with the addition of one CR for each line).
Conversely, using a web folder from explorer brings back the real
bytes (Windows file size matches Unix size)! Go figure. In any case,
using explorer to actually retrieve the real bytes from the Unix side
and then examining the files clearly reveals the issue with CR.

Web folders and Internet Explorer will always consider .cgi, .pl and .pm
files as binaries, as does FP2002 and earlier. Your copy of CuteFTP has
..cgi set up as ASCII.

I assume from your rather complete comments (thanks, by the way) that
there is no way to configure FP to publish in Unix file format. More
than a bit of a downer that. If there is, I'd like to know as I'm
otherwise relatively happy with FP.

If you publish with FP2003 in FTP mode, perl/cgi will be fine. However,
this does kill the FPextensions. Again, using subwebs, you may be able to
set the cgi-bin subweb to publish with FTP, and the rest of the site to
publish in HTTP mode. Again, I've never tried this, but do not see any
reason why it will not work. It does require subwebs on both ends. You
also cannot set permissions for new files in FrontPage.

Finally, are you aware of any cgi/pl/php addins for FP that will
improve its ability to deal with this?

The only addin I know of is the PHP Rocket, for editing PHP files in
FrontPage. There are none I know of for Perl.

Thanks again.

Your welcome