[CURL_ERRORS] => (18) Any idea?

[RomanceHarbor]

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

[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 ?

[DrByte]

Is this at all related to your other post about PayPal problems?
http://www.zen-cart.com/forum/showth...605#post393605

[RomanceHarbor]

Yes I am still having the same problem.

My host is MacHighway.com

Thanks for your help!

Kristy

[RomanceHarbor]

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!

[DrByte]

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

[ses707]

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

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

[DrByte]

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.

[DrByte]

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

[ses707]

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!

:)