[CURL_ERRORS] => (18) Any idea?

I have spent the last two days on the phone with Paypal and my host company, and so far all that I have been able to learn is that it is not related to paypal, or my host company. I must be doing something wrong.

If you have any ideas I would be incredibly thankful.

Response: 
Array
(
    [] => 
    [CURL_ERRORS] => (18) transfer closed with -1 bytes remaining to read
)

(18) transfer closed with -1 bytes remaining to read
Array
(
    [url] => "https://api-3t.paypal.com/nvp"
    [content_type] => text/plain; charset=utf-8
    [http_code] => 200
    [header_size] => 197
    [request_size] => 326
    [filetime] => -1
    [ssl_verify_result] => 0
    [redirect_count] => 0
    [total_time] => 1.142
    [namelookup_time] => 0.261
    [connect_time] => 0.315
    [pretransfer_time] => 0.703
    [size_upload] => 487
    [size_download] => 142
    [speed_download] => 124.34325744308
    [speed_upload] => 426.44483362522
    [download_content_length] => 141
    [upload_content_length] => 487
    [starttransfer_time] => 0.704
    [redirect_time] => 0

The only other times I've seen this happen was when the hosting company's server was truncating or dropping information, or prematurely ending the CURL session while talking to the other server (whether paypal or authorize.net etc).

1and1 appeared to be problematic. Who's your host ?

Is this at all related to your other post about PayPal problems?
http://www.zen-cart.com/forum/showthread.php?p=393605#post393605

Yes I am still having the same problem.

My host is MacHighway.com

Thanks for your help!

Kristy

If it makes any difference, I am able to put through transactions using ipn.

Is there a way that I could use ipn and have the customer go to a paypal page that actually had the credit card option in plain view? Right now, they go to a page that asks them to sign into paypal, and there is a small link for credit cards on the bottom of the page.

Thanks!

Not as far as I know. The display of the page is dictated by PayPal.

DrByte:

The only other times I've seen this happen was when the hosting company's server was truncating or dropping information, or prematurely ending the CURL session while talking to the other server (whether paypal or authorize.net etc).

1and1 appeared to be problematic. Who's your host ?

1&1 Back to problematic.

Looks like this is what's responsible for my missing attributes and duplicate orders on PPEC. The PayPal server attempts many times to communicate with my server after receiving this error.

What's odd is I'm seeing it on a 1&1 dedicated server but not on the shared servers ... atleast for now :p

Do you happen to remember what you manipulated last time to get around this?

The last I 'remember' about specific things I (believed I) was able to code around was that 1and1 were sending back extra carriage-returns and other odd characters at the end of their CURL data, and mixing line-ending styles, etc, making the reported postback length actually shorter than the real data stream. This caused a number of headaches because I had to add regex filtering in several places to ensure that we had clean data.

If 1and1 have changed things again, I'll be ticked. But not surprised.

Something's awry with the response received from PayPal's servers.
The CURL response info even bears this out:

    [size_download] => 370
    [download_content_length] => 369
```It was expecting 369 characters, and got 370 ... presumably the null character at the end of the main response.

Seems to happen consistently when talking to PayPal servers from 1and1.



Seems to be fine when talking to authorize.net servers:

[url] => "https://www.authorize.net/gateway/transact.dll"
[content_type] => text/html
[http_code] => 200
[header_size] => 237
[request_size] => 217
[size_download] => 151
[download_content_length] => 151

and also fine for linkpoint:

[url] => "https://secure.linkpt.net:1129/LSGSXML"
[http_code] => 200
[header_size] => 40
[request_size] => 209
[size_download] => 280
[download_content_length] => 280

This problem is fixable on 1&1 servers by using the newer php5/curl/libcurl:
Rename the file
/ipn_main_handler.php
to
/ipn_main_handler.php5

Edit
/includes/modules/payment/paypal.php
Line 212

'notify_url' => zen_href_link('ipn_main_handler.php5', '', 'SSL',false,false,true),

Edit
/includes/modules/payment/paypalwpp.php
Line 206

$this->form_action_url = zen_href_link('ipn_main_handler.php5', 'type=ec&markflow=1&clearSess=1&stage=final', 'SSL', true, true, true);

Line 959

return zen_href_link('ipn_main_handler.php5', 'type=ec&clearSess=1', 'SSL', true,true, true);

Line 1601

$return_url = zen_href_link('ipn_main_handler.php5', 'type=ec', 'SSL', true, true, true);

Edit
/includes/modules/payment/paypal/paypal_curl.php
Line 170

$values['NOTIFYURL'] = urlencode(zen_href_link('ipn_main_handler.php5', '', 'SSL',false,false,true));

Line 203

$values['NOTIFYURL'] = urlencode(zen_href_link('ipn_main_handler.php5', '', 'SSL',false,false,true));

Edit
/includes/modules/payment/paypal/paypal_functions.php
Line 354

$address = HTTP_SERVER . DIR_WS_CATALOG . 'ipn_main_handler.php5?' . $postdata;

Edit
/includes/modules/payment/paypal/tpl_ec_button.php

<a href="<?php echo zen_href_link('ipn_main_handler.php5', 'type=ec', 'SSL', true, true, true); ?>"><img src="<?php echo MODULE_PAYMENT_PAYPALWPP_EC_BUTTON_IMG ?>" alt="<?php echo MODULE_PAYMENT_PAYPALWPP_TEXT_BUTTON_ALTTEXT; ?>" /></a>

You should also sign in to PayPal and change:
Profile -> Instant Payment Notification Preferences -> Instant Payment Notification (IPN) URL
to
http://www.mysite.com/ipn_main_handler.php5

If you are concerned with the language files telling you the correct URL to use you can also change:
/includes/languages/english/modules/payments/paypal.php
Line 13

And
/includes/languages/english/modules/payments/paypalwpp.php
Line 20

DrByte thank you for taking the time to look at this, it jolted me into fix mode!

:)

ses707,
That's excellent.
I'm trying to think of some less-instrusive ways to make that change ... without touching so many files.
Perhaps a redirect of sorts in the original ipn_main_handler.php
(ie: rename the original one to .php5, and add a new file that just redirects to the new one, along with all the applicable URL params if needed)?

Oh, and one note ... you mention 2 files which do not currently use CURL, so probably don't need to be touched, since they are IPN-only activity, at least "today" in ZC v1.3.x:

/includes/modules/payment/paypal.php
/includes/modules/payment/paypal/paypal_functions.php

DrByte:

ses707,
That's excellent.
I'm trying to think of some less-instrusive ways to make that change ... without touching so many files.
Perhaps a redirect of sorts in the original ipn_main_handler.php
(ie: rename the original one to .php5, and add a new file that just redirects to the new one, along with all the applicable URL params if needed)?

I think ideally this should be reviewed at the development level as to why we're not using a

define('FILENAME_IPN_MAIN_HANDLER', 'ipn_main_handler.php');

In the meantime I'm wondering if an 'include' or 'require' would parse with the .php5 if it's called from a .php.

I've been pondering the use of a define.

I also am uncertain about the .php5 being parsed properly as you mentioned. One way to find out !!

I've been experiencing inconsistencies with this still and have some questions.
#1 - I have both PayPal IPN and PayPal WPP running at the same time (so we grab new customers that want to follow the regular checkout and just pay with a credit card and then we grab the current PayPal customers that want to use express checkout).
#2 - PayPal PDT is setup which I believe is causing all the problems I am experiencing.

Symptoms:

1. PayPalWPP orders sometimes have full order information in the admin section ... it seems that if PDT gets in first we get no order details and if it gets in last (and aborts) we get full order details ... PayPal order always contains full details.
2. PayPal IPN orders almost never have good details ... it looks like PDT beats IPN everytime and then none of the order details are in the admin section or on the PayPal order.

So my questions are:

1. How does a PDT entry differ from an IPN entry when it comes to order details? Is it possible we have another 1&1 glitch?
2. If I turn off PDT on PayPal site and leave the token key in does the module not serialize orders and I have a problem?
3. If I remove the PDT token key and I turn off PDT on PayPal does the PayPal IPN module still function 100% as it used to or are we dependant on PDT now?

Edit:
The above fix is appearantly not 100%, I have received 1 order out of about 100 that still shows a curl error...

ses707:

3. If I remove the PDT token key and I turn off PDT on PayPal does the PayPal IPN module still function 100% as it used to or are we dependant on PDT now?If you turn off PDT on both ends, it functions normally as IPN ... waiting for the IPN in order to release the order.

I've been doing a bit of experimenting (as I have the same problem with fasthosts here in the UK, which i think is the same setup stuff as 1and1). Basically it seems to be just the PayPal secure url it's having a problem with.

This simple PHP can demonstrate the problem, to the paypal URL we get the -1 bytes problem, to any other SSL i've tried (including https://www.paypaldeveloper.com/) come through without errors.

Smacks of some wacky issue on the PayPal side?, it seems to work to other SSLs in and around the paypal network. Perhaps some OS issue on the API server side?

<?php // // A very simple example that gets a HTTP page. // $ch = curl_init(); if (isset($_GET["url"])) { curl_setopt ($ch, CURLOPT_URL, $_GET["url"]); } else { curl_setopt ($ch, CURLOPT_URL, "https://api-3t.paypal.com/nvp"); } curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1); //curl_setopt ($ch, CURLOPT_TIMEOUT, 30000); curl_setopt ($ch, CURLOPT_FOLLOWLOCATION,0); curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST,2); curl_setopt ($ch, CURLOPT_FORBID_REUSE, true); //curl_setopt ($ch, CURLOPT_POST,1); curl_setopt ($ch, CURLOPT_HTTP_VERSION, "1.0"); curl_setopt ($ch, CURLOPT_HEADER, 0); $response = curl_exec($ch); $commError = curl_error($ch); $commErrNo = curl_errno($ch); $commInfo = @curl_getinfo($ch); curl_close($ch); $errors = ($commErrNo != 0 ? "\n(" . $commErrNo . ') ' . $commError : ''); // do debug/logging print "<PRE>"; print $response; print $errors . ($commErrNo != 0 ? "\n" . print_r($commInfo, true) : ''); PRINT "</PRE>"; ?>

Fasthosts servers have a number of other problems related to SSL, discussed around the forum.

Personally, I wouldn't waste my time with them.
You may choose otherwise -- naturally that's up to you.

If you choose to continue the testing you've started, you may want to look into whether PHP5 vs PHP4 makes any difference. You might even log a call with PayPal's tech support, although I doubt they'll change their postback methods for your hosting arrangements.

IMO based on experience with various clients and a number of folks on the support forum here, it seems that while 1and1 and fasthosts may be well-known names and their hosting services may be low-cost, they really are best-suited for a certain niche, and apparently ecommerce and SSL are not their strengths.

Thanks Doc, i'm very much inclined to agree with you.

ZC would work with their crippled setup with enough work arounds but this problem seems to be related to libcurl version. FH have php 4.3.1 and libcurl 7.10.2 (running CGI on IIS btw).

The rest of the world have PHP5 and libcurl 7.15, or at least PHP 4 with 7.15. No amount of dl() and other wacky ideas have helped get 7.15 loading.

Likely hood of change? PHP0

If you're not using paypal you have to backup your DB, put the full ZC install onto the shared windows space, install it and restore your DB. (the DB steps are just cos i dont know how to tell ZC it's already installed). It does work okay except for curl related stuff. I think IPN might work now for me, not sure.

bobf