Hi, I recently had to shift servers and since then I got an email from paypal:
http://www.absolutedirectory.com/...n/links/postback.cgi
If you do not recognize this URL, you may be using a service provider that is using IPN on your behalf. Please contact your service provider with the above information. If this problem continues, IPNs may be disabled for your account.
Thank you for your prompt attention to this issue.
So I spoke to the host techie who is migrating all my sites to the new server and his reply was:
I can confirm that the other Perl CGI scripts work and the directory is overall operational, so it is only this one that makes problems and nothing distinguishes it from the setup of the others.
After extensive digging in the web server error logs found the following records:
==> /usr/local/apache/logs/error_log <==
[Thu Feb 04 12:37:46 2010] [error] [client IP_address] postback.cgi called, but no payment method postback could be identified. at postback.cgi line 60.
[Thu Feb 04 12:37:46 2010] [error] [client IP_address] Premature end of script headers: postback.cgi
[Thu Feb 04 12:37:46 2010] [error] [client IP_address] File does not exist: /home/absolutd/public_html/500.shtml
The error message "postback.cgi called, but no payment method postback could be identified. at postback.cgi line 60" does not seem a generic error message that a script has dies, it includes explanation of the problem, so it must be generated by the Perl interpreter and not the web server. The Perl interpreter does not know of payments, so it must be an error generated by the script itself.
Opening the file I found this comment on top:
# This file (postback.cgi) is meant for handling postback for "remote" payment
# methods such as PayPal or WorldPay. Normal users should not reach this page,
# as this typically produces a blank (or nearly blank) page. No sort of user
# authentication is performed, and no user-based functionality is provided.
# Additionally, if no postback is found, or an error occurs, an ordinary die
# (producing a 500 Internal Server Error) is performed - payment providers
# often recognize this and will post the request again after a certain amount
# of time.
All is self explanatory about this comment and the script generates the error on line 60 which says:
die 'postback.cgi called, but no payment method postback could be identified.';
This confirms that the error is generated by the script termination with the "die" function and that the Error 500 is generated because this file should not be called by a web browser because it does not send the web server headers.
So, looks like this is normally not called and should be properly addressed by the respective payment system.
I would however recommend that you take this report along with the report from Paypal to the developers of the script so they can guide you if this is normal or not.
Further to this, you must know that with the migration, the IP address at which your site operate is changed to 213.229.79.204, so if there is some setting that should reflect which addresses are allowed to generate payments, this has to be set to this IP or the server primary IP that is 213.229.77.93.
Can anyone shed any light please? I am running 3.1.0 Gossamer Links if that helps find the cause of the error.
Many thanks,
Jez.
http://www.absolutedirectory.com
Quote:
Please check your server that handles PayPal Instant Payment Notifications (IPN). Instant Payment Notifications sent to the following URL(s) are failing: http://www.absolutedirectory.com/...n/links/postback.cgi
If you do not recognize this URL, you may be using a service provider that is using IPN on your behalf. Please contact your service provider with the above information. If this problem continues, IPNs may be disabled for your account.
Thank you for your prompt attention to this issue.
So I spoke to the host techie who is migrating all my sites to the new server and his reply was:
Quote:
At first glance this seems like a permission problem on the script being executed or something similar, but permission levels are OK and the script still generates the dreaded error 500. I can confirm that the other Perl CGI scripts work and the directory is overall operational, so it is only this one that makes problems and nothing distinguishes it from the setup of the others.
After extensive digging in the web server error logs found the following records:
==> /usr/local/apache/logs/error_log <==
[Thu Feb 04 12:37:46 2010] [error] [client IP_address] postback.cgi called, but no payment method postback could be identified. at postback.cgi line 60.
[Thu Feb 04 12:37:46 2010] [error] [client IP_address] Premature end of script headers: postback.cgi
[Thu Feb 04 12:37:46 2010] [error] [client IP_address] File does not exist: /home/absolutd/public_html/500.shtml
The error message "postback.cgi called, but no payment method postback could be identified. at postback.cgi line 60" does not seem a generic error message that a script has dies, it includes explanation of the problem, so it must be generated by the Perl interpreter and not the web server. The Perl interpreter does not know of payments, so it must be an error generated by the script itself.
Opening the file I found this comment on top:
# This file (postback.cgi) is meant for handling postback for "remote" payment
# methods such as PayPal or WorldPay. Normal users should not reach this page,
# as this typically produces a blank (or nearly blank) page. No sort of user
# authentication is performed, and no user-based functionality is provided.
# Additionally, if no postback is found, or an error occurs, an ordinary die
# (producing a 500 Internal Server Error) is performed - payment providers
# often recognize this and will post the request again after a certain amount
# of time.
All is self explanatory about this comment and the script generates the error on line 60 which says:
die 'postback.cgi called, but no payment method postback could be identified.';
This confirms that the error is generated by the script termination with the "die" function and that the Error 500 is generated because this file should not be called by a web browser because it does not send the web server headers.
So, looks like this is normally not called and should be properly addressed by the respective payment system.
I would however recommend that you take this report along with the report from Paypal to the developers of the script so they can guide you if this is normal or not.
Further to this, you must know that with the migration, the IP address at which your site operate is changed to 213.229.79.204, so if there is some setting that should reflect which addresses are allowed to generate payments, this has to be set to this IP or the server primary IP that is 213.229.77.93.
Can anyone shed any light please? I am running 3.1.0 Gossamer Links if that helps find the cause of the error.
Many thanks,
Jez.
http://www.absolutedirectory.com