submit to FormMail.pl throwing some error.
V S Rawat
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, webm...@mydomain.com 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="my...@mydomain.com">
<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> </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.
--
Rawat
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 S Rawat
Thanks,
I had googled and downloaded one of the scripts for it. Any tips where
can I better one?
Thanks.
--
V
Joost Diepenmaat
> --start
> Internal Server Error
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
>
> Please contact the server administrator, webm...@mydomain.com 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?
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
J. Gleixner
[...]
> 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. Gleixner
[...]
> 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:
John Bokma
> 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.
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
Joost Diepenmaat
> V S Rawat <vsr...@gmail.com> wrote:
>
>> my file ContactUs.html is kept in /www
>
> Tip: you might want to rename it to contact-us.html
Maybe, but the're no technical reason to do so.
>> 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),
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.
John Bokma
> John Bokma <jo...@castleamber.com> writes:
>
>> V S Rawat <vsr...@gmail.com> wrote:
>>
>>> my file ContactUs.html is kept in /www
>>
>> Tip: you might want to rename it to contact-us.html
>
> 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
>>> 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),
>
> 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?
Jim Gibson
<faw...@gmail.com> wrote:
> On Sat, 06 Sep 2008 01:16:05 +0530, V S Rawat wrote:
>
> > 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.
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?
--
Jim Gibson
Joost Diepenmaat
> Joost Diepenmaat <jo...@zeekat.nl> wrote:
>> John Bokma <jo...@castleamber.com> writes:
>>> V S Rawat <vsr...@gmail.com> wrote:
>>>> my file ContactUs.html is kept in /www
>>> Tip: you might want to rename it to contact-us.html
>>
>> 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.
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.
>>>> 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),
>>
>> Again, there's no real reason to do so.
>
> 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.
>> And separating files out by
>> "type" can really mess up your website/code structure.
>
> Why?
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.
John Bokma
> John Bokma <jo...@castleamber.com> writes:
>
>> Joost Diepenmaat <jo...@zeekat.nl> wrote:
>>> John Bokma <jo...@castleamber.com> writes:
>>>> V S Rawat <vsr...@gmail.com> wrote:
>>>>> my file ContactUs.html is kept in /www
>>>> Tip: you might want to rename it to contact-us.html
>>>
>>> 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.
>
> In which case it won't matter what the case is.
Yes, it does. Imagine being on the phone with someone...
>> Yes there is: security for one.
>
> 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.
>>> And separating files out by
>>> "type" can really mess up your website/code structure.
>>
>> Why?
>
> 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.
Leon Timmermans
> In article <48c192b4$0$199$e4fe...@news.xs4all.nl>, Leon Timmermans
> <faw...@gmail.com> wrote:
>
>
> 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
Mark Clements
> On Fri, 05 Sep 2008 16:57:45 -0700, Jim Gibson wrote:
>
>> In article<48c192b4$0$199$e4fe...@news.xs4all.nl>, Leon Timmermans
>> <faw...@gmail.com> wrote:
>>
>>
>> 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.
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 S Rawat
Where can I find a better/ sleaker version to download and use for free?
>
> Regards,
>
> Leon
Thanks.
--
Rawat
V S Rawat
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.
--
V
Jim Gibson
<faw...@gmail.com> wrote:
> On Fri, 05 Sep 2008 16:57:45 -0700, Jim Gibson wrote:
>
> > In article <48c192b4$0$199$e4fe...@news.xs4all.nl>, Leon Timmermans
> > <faw...@gmail.com> wrote:
> >
> >
> > 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.
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.
>
> > 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.
I found the code nicely indented and easy on the eyes.
>
> > What do you recommend as being better? And why?
>
> 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.
--
Jim Gibson