ماهو الارور 500

[www.com]

بسم الله الرحمن الرحيم

ركبت برنامج اوتو رانك على سيرفرين مجانين الاول في f2s و الثاني virtualave و كل ما اردت الدخول الي صفحة السيتب طلعلي ارور 500 فارجو ممن يعرف سبب ظهور هذا الارور ان يفينا و له جزيل الشكر

[mabsoot]

Error 500
Messages reporting 'Error 500' or 'internal server error' can be caused by a number of possible problems. This section briefly lists and explains some of the commonest causes of such errors.

Execute permissions not set correctly.
For a script to run, the permissions bits must be set to allow it to be executed. If your server runs as nobody, you'll need to make your script world-executable with:

chmod a+x MyScript.pl

If the server runs scripts using your own UID, you can get away with

chmod u+x MyScript.pl

Bad interpreter line
A Perl script should begin with a line that identifies the Perl interpreter on the local system, e.g.


#!/usr/local/bin/perl

If the line doesn't give the path of a valid Perl interpreter, an error will be generated. You can usually find out the path to the interpreter by using:


which perl

The interpreter line must be the first line of the script, and must begin with '#!'. The same principles apply when writing shell scripts using sh, csh etc.

Syntax error in script
Any syntax errors in your script will cause a 500 error. Perl allows you to check the script at the command line with:


perl -c MyScript.pl

Another useful option is:


perl -w MyScript.pl

which issues compiler warnings that may highlight possible runtime problems with the script. You may also find the error message generated by Perl in your system's error log after a server error.

Missing required file
If a library requested with 'require' or 'use' can't be found, a 500 error will occur. Normally syntax-checking the script should detect this error, but in some cases the environment in which scripts are executed by the server may be different from the environment set up when the script is run at the command-line. Perl might find the library file correctly in one case, but not in another.

Runtime error in script
If the script runs into an execution error - for instance, a file not found, division by zero etc. - then a 500 error will occur. See below for a tip on how to trap runtime errors for easier debugging. Runtime errors, particularly of the 'file not found' variety, can often be caused by differences between the Perl environment when executed under the server and the environment when executed from the command line. Trapping the error and printing the full path to the file that the script thinks it wants can often be very helpful.

Invalid HTTP header sent
The first output sent by a script must always be a valid HTTP header, typically:


Content-type: text/html

The headers must then be followed by two linefeeds before the actual content begins. Remember to check that print statements writing to other streams really do write to those other streams and not to standard output. Also beware of debugging comments written to standard error: some servers take their input from either STDOUT or STDERR, and because STDERR is line-buffered (text written to STDERR is sent out as soon as the line is complete) while STDOUT typically defaults to block-buffering (text is written when enough of it has been printed to fill a buffer), STDERR may 'get there first'. The following script would cause errors on some systems:

#!/usr/local/bin/perl
print "Content-type: text/plain\n\n";
print STDERR "OK so far\n";
print "Succeeded.";

because the server would see the 'OK so far' first, and fail to make sense of it. You can force line-buffering on STDOUT with:


$|=1;

placed early on in your script, which is probably a good thing to do anyway.

Wrong version of Perl
Make sure that you're not trying to run a Perl 5 script on a Perl 4 (or earlier!) interpreter. Try:


perl -e `print $]`

at the UNIX prompt to see which version of Perl you're running. If it turns out to be Perl 4, there may be a Perl 5 interpreter installed in the same directory, but with the name perl5. Note also that Perl 4 scripts run on Perl 5 interpreters may give problems; in particular, strings that contain '@' may cause errors; '@' now needs to be escaped by inserting a backslash before it wherever it occurs in a string.

Server configuration errors
The bottom line, of course, is that the server may be configured wrongly. NetScape Commerce Server, for example, will throw a server error if you use POST to invoke a script stored in a directory that the server doesn't think should hold scripts. If using POST causes an error, and using GET (on the same script) returns the text of the script, it's quite likely that the directory isn't recognised as a valid directory for CGI scripts. At which point there's nothing for it but to descend into the obj.conf file (on NetScape servers) with pick and shovel. But remember, if you're not sure what you're doing, "Meddle not in the affairs of servers, for they are subtle, and quick to anger."

One of the best techniques for simplifying debugging is to use eval to trap runtime errors. A good general model for scripts might be:

{ ... initialization code ... }
eval("main");
if ($@) {
print "Content-type: text/plain\n\n",
"The script failed because the error\n$@\noccurred.";
}
sub main { ... }

If you get a 500 error, then you know that it's caused by something outside the main subroutine, typically one of the other error causes discussed above. If a runtime error occurs inside the main subroutine, you get useful debugging output to help you identify it.

Errors that occur during execution of scripts should normally logged to your server's error log. Unlike the default message that appears in the browser window, which simply notes that an error occurred and gives the class of the error, the error log will usually contain the actual error message issued by the Perl interpreter. Depending on where and how your site is hosted, you may or may not have access to the error log, but if you do, you should use it. Note that the location of the log will vary from system to system, depending on how your server is set up. The error log will typically be stored at the same location as the main access log.

[ابو يعقوب]

كثيرة هي الرسائل التي يصدرها ملقم HTTP وجميعها هدفها إفاده بالطلب الذي تم إرساله .
هذه الرسائل تسمى أكواد الحـــــــــــــاله (Status Code).

على سبيل المثال :
اذا طلبت إحدى الصفحات ولم يجدها الملقم فإنه يعود بالخطأ 404 .
إذا كانت الصفحة قد انتقلت الى مكان آخر فإنه يعود بالخطأ 301 .
وفي الغالب فإن أكوادالحالة تتكون ثلاث خانات رقميه تمثل رقم الخطأ ورساله قصيره تشرح الخطأ.
وإليك قائمة ببعض هذه الأخطاء :

• 200 :ويعني نجاح الطلب.
• 204 : ويعني خطأ عدم الإستجابه .
• 301 : ويعني انتقال الملف المطلوب الى مكان آخر .
• 401 : ويعني خطأ عدم التخويل بالدخول .
• 403 : ويعني أن الصفحة محظورة أو غير شرعيه .
• 404 : ويعني عدم وجود الصفحة حالياً .
• 500 : ويعني وجود خطأ في ملقم انترنت (راجع رسالة مبسوط السابقه) .
• 501 : غير مطبق .

لاحظ أن الأخطاء 5xx هي أخطاء في المزود .
والأخطاء 4xx هي أخطاء من العميل .

نأتي الى أمتع جزء في العمليه وهو أنك كمبرمج بيرل تستطيع ارسال أي كود من هذه الأكواد وعرضه للمستخدم .

مثال :
اذا أردت ارسال الخطأ 204 (في حال مخالفته أمراً ما مثلاً) تستطيع كتابة الكود التالي :

#!/usr/local/bin/perl
print "Content-type: text/plain", "\n";
print "Status: 204 No Response", "\n\n";
print "المفروض أن لا ترى هذه الرساله إذا لم ترها فإن متصفحك ", "\n";
print "قد عرض لك خطأ عدم الإستجابه بشكل جيد", "\n";
exit (0);

مثال آخر :
تريد حجب الزوار الذين لم يأتوا من سيرفر معين (saudi.net.sa مثلاً) :

#!/usr/local/bin/perl
$remote_host = $ENV{'REMOTE_HOST'};
print "Content-type: text/plain", "\n";
if ($remote_host eq "saudi.net.sa") {
        print "Status: 200 OK", "\n\n";
        print "حسناً! تستطيع الدخول !", "\n";
} else {
        print "Status: 400 Bad Request", "\n\n";
        print "آسف! تستطيع الدخول فقط من سعودي نت!", "\n";
}
exit (0);

[www.com]

طيب وش الحل مع هذا الخطأ؟؟؟

[ابو يعقوب]

راجع ما كتبه مبسوط فقد بسط الكلام حول الخطأ 500 .والحلول موجوده في نفس المقال .