submit to FormMail.pl throwing some error.

V

V S Rawat

I am creating a website.

The website root is /www at server.

my file ContactUs.html is kept in /www

FormMail.pl is kept in /www/cgi-bin
It was downloaded from
http://nms-cgi.sourceforge.net/formmail_compat-3.14c1/FormMail.pl
No changes done.

..FormMail.conf is also at /www

When I click submit, instead of displaying thanks.html (in the same
folder, it shows this message:

--start
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.

Please contact the server administrator, (e-mail address removed) and
inform them of the time the error occurred, and anything you might have
done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 404 Not Found error was encountered while trying to use
an ErrorDocument to handle the request.
--end

HTML SOURCE
--start
<form id=contactform action="/cgi-bin/FormMail.pl" method=post>
<input type=hidden id=recipient value="(e-mail address removed)">
<input type=hidden id=subject value="Website Contact Form">
<input type=hidden id=redirect value="Thanks.html">
<input type=hidden id=sort value="order:email,comments">
<input type=hidden id=required
value="email,realname,comments">
<table>
<tr>
<td>&nbsp;</td>
<td>* marked fields are mandatory.</td>
</tr>
<tr>
<td align=right>*Your Name:</td>
<td><input type=text id=realname maxlength=100
style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>Address Line 1:</td>
<td><input type=text id=address_line1
maxlength=100 style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>Address Line 2:</td>
<td><input type=text id=address_line2
maxlength=100 style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>Phone:</td>
<td><input type=text id=phone maxlength=100
style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td align=right>*Email:</td>
<td><input type=text id=email maxlength=100
style="width: 220px; color: #00267F; font-weight: bold;
background-color: lightblue"></td>
</tr>
<tr>
<td style="text-align: right;
vertical-align:top">*Comments:</td>
<td><textarea id=comments rows=4 cols=25
style="width: 220px; height: 80px; color: #00267F; font-weight: bold;
background-color: lightblue; white-space: pre; overflow:
auto"></textarea></td>
</tr>
<tr>
<td></td>
<td align=right><input type=submit id=submit
value=Submit style="color: #00267F; font-weight: bold; background-color:
lightblue"></td>
</tr>
</table>
</form>
--end

What went wrong?

It was working OK during the day. I did some tweaking and it is not
working now.

btw, where are server logs kept. I am not able to find anything on server.

Thanks.
 
L

Leon Timmermans

I am creating a website.

The website root is /www at server.

my file ContactUs.html is kept in /www

FormMail.pl is kept in /www/cgi-bin
It was downloaded from
http://nms-cgi.sourceforge.net/formmail_compat-3.14c1/FormMail.pl No
changes done.

.FormMail.conf is also at /www

Oy vey! That script is mess. Please do yourself a favor and get something
better.
What went wrong?

It was working OK during the day. I did some tweaking and it is not
working now.

btw, where are server logs kept. I am not able to find anything on
server.

Without server logs, we can't say anything. You could add
use CGI::Carp qw(fatalsToBrowser);
To your script to get those errors to your browser. That will hopefully
make clear what's wrong.

Regards,

Leon
 
V

V S Rawat

Oy vey! That script is mess. Please do yourself a favor and get something
better.


Without server logs, we can't say anything. You could add
use CGI::Carp qw(fatalsToBrowser);
To your script to get those errors to your browser. That will hopefully
make clear what's wrong.

Regards,

Leon

Thanks,

I had googled and downloaded one of the scripts for it. Any tips where
can I better one?

Thanks.
 
J

Joost Diepenmaat

V S Rawat said:
--start
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.

Please contact the server administrator, (e-mail address removed) and
inform them of the time the error occurred, and anything you might
have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 404 Not Found error was encountered while trying to
use an ErrorDocument to handle the request.

So what's in the error logs?
 
J

J. Gleixner

V S Rawat wrote:
[...]
When I click submit, instead of displaying thanks.html (in the same
folder, it shows this message:

--start
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request. [...]
What went wrong?

It was working OK during the day. I did some tweaking and it is not
working now.

Ahhh.. that's probably what went wrong.
btw, where are server logs kept. I am not able to find anything on server.

Wherever your server is configured to put them. /var/log/httpd-error.log?

First, ensure you don't have a typo: perl -c FormMail.pl
Second, look at your 'tweeking', for problems. Compare the original with
your version.
Third, as the user that's running your Web server, try to run it via the
command line: ./FormMail.pl
 
J

J. Gleixner

V S Rawat wrote:
[...]
When I click submit, instead of displaying thanks.html (in the same
folder, it shows this message:

Also. You refer to 'thanks.html', but your HTML shows:
 
J

John Bokma

V S Rawat said:
my file ContactUs.html is kept in /www

Tip: you might want to rename it to contact-us.html
FormMail.pl is kept in /www/cgi-bin

Advice: you might want to keep your cgi-bin side by side with www, not
*in* www (i.e. your DOCUMENT_ROOT),
.FormMail.conf is also at /www

Advice: keep it out both www and cgi-bin. It should never be in www IMO.
Internal Server Error

Check your error_log.

Also, if you edit the file locally, it's often a very smart thing to

perl -c FormMail.pl

before you upload.

btw, where are server logs kept. I am not able to find anything on
server.

Ask the company you're hiring webspace from.
 
J

Joost Diepenmaat

John Bokma said:
Tip: you might want to rename it to contact-us.html

Maybe, but the're no technical reason to do so.
Advice: you might want to keep your cgi-bin side by side with www, not
*in* www (i.e. your DOCUMENT_ROOT),

Again, there's no real reason to do so. And separating files out by
"type" can really mess up your website/code structure. IMO it's much
better to keep files that are functionally related together.
 
J

John Bokma

Joost Diepenmaat said:
Maybe, but the're no technical reason to do so.

Hence tip. A technical reason might be that your webserver is case-
sensistive because the underlying filesystem is. A non-techincal one:
CamelCase is supposed to be less readable (and a technical one might be
that keyword-keyword is rewarded by SEs versus KeywordKeyword
Again, there's no real reason to do so.

Yes there is: security for one.
And separating files out by
"type" can really mess up your website/code structure.

Why?
 
J

Jim Gibson

Leon Timmermans said:
Oy vey! That script is mess. Please do yourself a favor and get something
better.

In what way is that script a "mess"? The NMS scripts are touted for
robustness and security. Yours is the first criticism I have
encountered. The script source file is certainly neat enough.

I have not used any NMS scripts or studied them in any detail, but they
are frequently recommended by others.

What do you recommend as being better? And why?
 
J

Joost Diepenmaat

John Bokma said:
Hence tip. A technical reason might be that your webserver is case-
sensistive because the underlying filesystem is.

In which case it won't matter what the case is.
A non-techincal one: CamelCase is supposed to be less readable (and
a technical one might be that keyword-keyword is rewarded by SEs
versus KeywordKeyword

I'll grant you that.
Yes there is: security for one.

Bah. The only thing you're protecting against with this is bad system
management. And that can will mess up security no matter where you
place your CGI scripts.

One reason is, that I want my scripts to be portable. For instance. I
would like to refer to an image using a relative URL from a CGI: print
q{ <img src="foo.png">} I don't want to have to find out where the
images are just because I just moved the whole app to some other
directory.
 
J

John Bokma

Joost Diepenmaat said:
In which case it won't matter what the case is.

Yes, it does. Imagine being on the phone with someone...
Bah. The only thing you're protecting against with this is bad system
management.

Say hello to virtual hosting.
And that can will mess up security no matter where you
place your CGI scripts.

Yes, and a nuclear war makes things even worse. Security is about reducing
probabilities.
One reason is, that I want my scripts to be portable. For instance. I
would like to refer to an image using a relative URL from a CGI: print
q{ <img src="foo.png">} I don't want to have to find out where the
images are just because I just moved the whole app to some other
directory.

Pfft. Well, I won't put my custom Perl modules in the same directory as
the images, the Perl program, configuration file(s), templates, etc and
all under the document root. YMMV, but it sounds very odd to me, and I
would never recommend such a set up.
 
L

Leon Timmermans

In what way is that script a "mess"? The NMS scripts are touted for
robustness and security. Yours is the first criticism I have
encountered. The script source file is certainly neat enough.

It's a 3306 lines, 75 kilobyte script. That says enough in my opinion.
I have not used any NMS scripts or studied them in any detail, but they
are frequently recommended by others.

Given the fact that it is a drop-in replacement for that awful script
from "Matt's script archive" this architecture is unavoidable, but that
doesn't make it pretty to look at.
What do you recommend as being better? And why?

There is a version of it that is split out, that is already infinitely
better.

Regards,

Leon
 
M

Mark Clements

Leon said:
It's a 3306 lines, 75 kilobyte script. That says enough in my opinion.
Where I work (a Java and 4GL shop) there is a Java class with 12500
lines. One of its methods has *8000* lines composed of the same 20 or so
lines of code copied-and pasted and modified for different data values.
On one occasion the compiler even refused to compile it
(MethodTooComplexException or somesuch). This is an extreme example but,
unfortunately, fairly typical. Fortunately *I* don't have to maintain it :)



Mark
 
V

V S Rawat

It's a 3306 lines, 75 kilobyte script. That says enough in my opinion.


Given the fact that it is a drop-in replacement for that awful script
from "Matt's script archive" this architecture is unavoidable, but that
doesn't make it pretty to look at.


There is a version of it that is split out, that is already infinitely
better.

Where can I find a better/ sleaker version to download and use for free?
Regards,

Leon


Thanks.
 
V

V S Rawat

Oy vey! That script is mess. Please do yourself a favor and get something
better.


Without server logs, we can't say anything. You could add
use CGI::Carp qw(fatalsToBrowser);
To your script to get those errors to your browser. That will hopefully
make clear what's wrong.

I have added the above line as the first line in the script (before use
Strict), but execution is still showing the same message and not showing
the real errors on the browser page. What to do?

I am noob so I am not really aware of server error logs, etc. I have
checked the root of entire server but I couldn't really locate any error
logs having any decipherable message that I can understand. Where should
I look?

I think it is a zencart type installation, but my site doesn't have any
database associated, just static html 4 pages.

And, irrespective of actual error logs, could anyone just enumerate a
few "main probables" (errors) that I can fiddle around with. Repeat, it
was working in the day and then I validation the html/css against w3c
standards to make 0 error/0 warning and it stopped working.
Regards,

Leon

Thanks.
 
J

Jim Gibson

Leon Timmermans said:
It's a 3306 lines, 75 kilobyte script. That says enough in my opinion.

The length of the code may be due to the complexity of the task.
Shorter is not always better. Shorter versions may leave out steps
required for safety, reliability, handling special cases, or error
checking and reporting.
Given the fact that it is a drop-in replacement for that awful script
from "Matt's script archive" this architecture is unavoidable, but that
doesn't make it pretty to look at.

I found the code nicely indented and easy on the eyes.
There is a version of it that is split out, that is already infinitely
better.

There is a tradeoff in having all of the code in one file (easy to
edit, copy, install) and splitting the same code into multiple source
files (easier to maintain). Neither approach is necessarily better than
the other.

Can you provide a link to the "split out" version so we can evaluate it?

Thanks.
 

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

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top