After each checkout I find two error messages in the log:

Location http://test.sidepotsinternational.com/cart/checkout?op=next
Referrer http://test.sidepotsinternational.com/cart/checkout
Message fread(): SSL: fatal protocol error in /home/darrenoh/public_html/includes/common.inc on line 422.

Location http://test.sidepotsinternational.com/cart/checkout?op=next
Referrer http://test.sidepotsinternational.com/cart/checkout?op=next
Message fread(): SSL: fatal protocol error in /home/darrenoh/public_html/includes/common.inc on line 422.

Comments

Darren Oh’s picture

Darren Oh
Primary language English
Location Lakeland, Florida
CreditAttribution: Darren Oh commented
Title: SSL Errors After Checkout » How to Stop Logging "fread(): SSL: fatal protocol error"?
Component: cart.module » other
Category: bug » support

This error is generated by the shipping page of the checkout process. It is generated whenever the USPS usps_get_rates function queries the USPS server. The file contrib/shipcalc/partners/usps.inc contains this code:

  /**
   * Ugly hack to work around PHP bug, details here:
   *   http://bugs.php.net/bug.php?id=23220
   * We strip out errors that look something like:
   *  warning: fread() [function.fread]: SSL fatal protocol error in...
   */
  $messages = drupal_set_message();
  $errors = $messages['error'];
  $count = 0;
  for ($i = 0; $i <= sizeof($errors); $i++) {
    if (strpos($errors[$i], 'SSL: fatal protocol error in')) {
      unset($errors[$i]);
      unset($_SESSION['messages']['error'][$i]);
    }
    else {
      $count++;
    }
  }
  if (!$count) {
    unset($_SESSION['messages']['error']);
  }
  // End of ugly hack.

This prevents the error message from displaying on screen, but it still shows up in the log. This is distracting, since the error message is generated twice for each purchase. Does anyone know how to prevent this message from being logged?

Darren Oh’s picture

Darren Oh
Primary language English
Location Lakeland, Florida
CreditAttribution: Darren Oh commented
Component: other » shipcalc
Darren Oh’s picture

Darren Oh
Primary language English
Location Lakeland, Florida
CreditAttribution: Darren Oh commented
Status: Active » Closed (won't fix)

The solution is to upgrade to PHP5.

JoshLangner’s picture

JoshLangner CreditAttribution: JoshLangner commented
Status: Closed (won't fix) » Active

Upgrading to PHP5 is not the solution. I still have the error being generated, and I have tested it with 5.1.6.

brmassa’s picture

brmassa CreditAttribution: brmassa commented
Status: Active » Closed (fixed)

Guys,

its already fixed on ec3

regards,

massa

ymmatt’s picture

ymmatt CreditAttribution: ymmatt commented
Category: support » bug
Status: Closed (fixed) » Active

I don't mean to open an old bug, but I'm experiencing this on the latest alpha release

gordon’s picture

gordon CreditAttribution: gordon commented
Version: 4.7.x-1.x-dev » 5.x-4.0-alpha6
Status: Active » Fixed

This is actually an issue with the server on the other side. From my investigations it is a because of a buggy IIS implementation. So far I have only really for this bug on test/development servers

ATM we are using the drupal_http_request() to communicate with the other servers, but if this still seems to be an issue I will write a replacement for this which will use curl if it is available.

ymmatt’s picture

ymmatt CreditAttribution: ymmatt commented

This is actually an issue with the server on the other side. From my investigations it is a because of a buggy IIS implementation. So far I have only really for this bug on test/development servers

Are you referring to the authorize.net servers? Or when running the transactions as test transactions?

This may or may not be related, but the ec_transaction table seems to be missing some key entries:

UID
payment_status
payment_date
due_date

These are all blank, is that normal?

gordon’s picture

gordon CreditAttribution: gordon commented

Are you referring to the authorize.net servers? Or when running the transactions as test transactions?

Yes this is the authorize.net servers

This may or may not be related, but the ec_transaction table seems to be missing some key entries:

UID
payment_status
payment_date
due_date

These are all blank, is that normal?

These are depreciated fields and before the final release of v4.0 these will be dropped. But before then the information needs to be converted to the new format.

ymmatt’s picture

ymmatt CreditAttribution: ymmatt commented

Thanks,

Where can I find the documentation on the new format so that I can work on this module, if not for everyone else, but at least for myself?

gordon’s picture

gordon CreditAttribution: gordon commented

Check out http://drupalecommerce.org/api where there are links to a couple of examples, and you can also checkout the paypal or authorize.net module

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

Alan D.’s picture

Alan D. CreditAttribution: Alan D. commented

I'm seeing this code in some other modules, did anyone simply try adding "@drupal_http_request()"? This should suppress the error, but I haven't the ability to test this myself.

So if you see this, try @ before adding the other code!