Paypal IPN HTTP/1.1-完全不提供任何响应，它是一个空字符串 [英] Paypal IPN HTTP/1.1 - doesn't provide any response at all, it is an empty string
问题描述
无法解释的结果可能会影响或将影响成千上万的网站管理员.
问题是Paypal根本没有对此请求做出回应.以下是我使用的示例代码以及程序员的注释:
The problem is Paypal doesn't give a response to this request AT ALL. Below is the sample code I use and also my programmer's comments:
"PayPal根本不对此请求作出任何响应，它是一个空字符串.您可以询问PayPal团队，是否应添加除'Host'和'HTTP/1.1'之外的任何内容以正确处理响应.难道'cmd'命令应该有另一个值? 我希望贝宝(PayPal)仅在2013年2月开放HTTP/1.1协议(如其电子邮件中所述).我不确定相同的脚本和主机如何处理不同的协议.该脚本现在无法在HTTP/1.1上使用我们已归档的代码，原因可能是在PayPal方面. 我一直在关注PayPal如何查询IPN脚本，并且当设置了HTTP 1.1时，它似乎陷入了某种循环.您仍然可以在ipnlogz.txt中看到它-'07％3A39％3A41'-即我的订单日期为'07:39:41'-它重复了5次！为什么?谁知道... 这仅意味着PayPal尝试对该脚本进行IPN 5次，但均未成功.仅当我将HTTP更新为1.0并重新上传脚本后，贝宝才会出现"VERIFIED"响应.此后，贝宝仍在查询它. 看来当HTTP = 1.1时，PayPal可以正确地获取所有内容，但不能正确地响应；然后出于某种原因又回到了相同的付款方式来创建另一个响应.使用HTTP 1.0就像一朵花:一个请求，一个响应，一切正常.我不知道这是怎么回事...
"PayPal doesn't give any response to this request at all, an empty string comes from it. You may ask the PayPal team, if anything besides 'Host' and 'HTTP/1.1' should be added to handle response properly. Could it be that the 'cmd' command should have another value? My expectation is that PayPal will open HTTP/1.1 protocols only in February 2013, as they state in their email. I'm not sure how the same script and host may handle different protocols. The script is not working now with HTTP/1.1 with the code we have on file, and the reason may be on PayPal's side. I was following how PayPal queries the IPN script, and it seems that it goes into some kind of loop, when there's HTTP 1.1 set. You can still see it yourself in ipnlogz.txt - '07%3A39%3A41' - i.e. '07:39:41' date of my order - it's repeated 5 times! Why? Who knows... it only means PayPal was trying to IPN this script 5 times and with no success. There appeared 'VERIFIED' response from PayPal only when I've updated HTTP to 1.0 and re-uploaded the script. After that, PayPal was still querying it. It seems when HTTP = 1.1 , PayPal is getting everything properly, but not responding properly; then for some reason gets back to create yet another response for the same payment. With HTTP 1.0 it's all like a flower: one request, one response, everything works. I don't know what's wrong with it...
Ps.我们不是在谈论无效"的回应. 无效"响应实际上是成功的一部分-但对于HTTP 1.1，PayPal根本不提供任何响应，它是一个空字符串."
Ps. We are not talking about an 'INVALID' response. An 'INVALID' response is actually part of success -but in the case of HTTP 1.1, PayPal doesn't provide any response at all, it is an empty string."
<?php
$req = 'cmd=_notify-validate';
$r='';
foreach ($_POST as $key => $value) {
$value = urlencode(stripslashes($value));
$req .= "&$key=$value";
$r.="{$key}: {$value}\n";
}
// post back to PayPal system to validate
$header .= "POST /cgi-bin/webscr HTTP/1.1\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Host: www.paypal.com\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n\r\n";
$fp = fsockopen ('www.paypal.com', 80, $errno, $errstr, 30);
#I also tried: $fp =fsockopen('ssl://www.paypal.com',443,$err_num,$err_str,30);
if (!$fp) {
$r.="----\nHTTP ERROR\n";
// HTTP ERROR
} else {
$r.="----\nReceived IPN request\n";
fputs ($fp, $header . $req);
while (!feof($fp)) {
$res = fgets ($fp, 1024);
}
fclose ($fp);
if (strcmp ($res, 'VERIFIED') == 0) {
$proceed=TRUE;
}
else{
$proceed=FALSE;
}
}
?>
PS.这是我们使用的脚本的notify_url部分:
PS. This is the notify_url part of the script we use:
<input type="hidden" name="notify_url" value="{$main_url}/index.php?action=ipn&user_id={$user_id}" />
，并且在沙盒中对其进行了测试.
and when it was tested in Sandbox it is working..
推荐答案
更改此内容:
// post back to PayPal system to validate
$header .= "POST /cgi-bin/webscr HTTP/1.1\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Host: www.paypal.com\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n\r\n";
$fp = fsockopen ('www.paypal.com', 80, $errno, $errstr, 30);
#I also tried: $fp =fsockopen('ssl://www.paypal.com',443,$err_num,$err_str,30);
对此:
// post back to PayPal system to validate
$header .= "POST /cgi-bin/webscr HTTP/1.1\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Host: www.paypal.com\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n";
$header .= "Connection: close\r\n\r\n";
$fp = fsockopen ('ssl://www.paypal.com', 443, $errno, $errstr, 30);
这:
if (strcmp ($res, 'VERIFIED') == 0) {
对此:
if (strcmp (trim($res), 'VERIFIED') == 0) {
几乎可以保证它能正常工作.
And it's pretty much guaranteed to work.
您当前的设置失败，因为PayPal在fsockopen欣然接受的响应中发送了Connection:keep-alive标头，从而使连接保持打开状态.
而HTTP库(例如cURL)将自动关闭连接.
Your current setup fails because PayPal sends a Connection: keep-alive header in the response which fsockopen gladly accepts, and thus it keeps the connection open.
Whereas a HTTP library such as cURL will close the connection automatically.
我的一般建议是；如果您不想控制跨到PayPal的每一位，请使用HTTP库(例如cURL)，而不要使用fsockopen(这只是一个简单的TCP连接).
(PayPal具有使用cURL的示例代码，可在 https://www.paypal.com/ipn 和 https://www.paypal.com/pdt )
My general suggestion is; if you don't want to control every single bit that goes across the line to PayPal, use a HTTP library such as cURL, rather than fsockopen which is just a plain TCP connection.
(PayPal has sample code using cURL available at https://www.paypal.com/ipn and https://www.paypal.com/pdt)
这篇关于Paypal IPN HTTP/1.1-完全不提供任何响应，它是一个空字符串的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
