"An AJAX HTTP error occurred" when getting shipping quotes in 7.x-2.x-dev:

Wasn't getting this error in XAMPP, but once deployed, the error reared its head.

Watchdog reports:
Notice: Undefined offset: 1 in drupal_http_request() (line 920 of /home/includes/common.inc).
and
Notice: Undefined offset: 2 in drupal_http_request() (line 924 of /home/includes/common.inc).

Seems related to http://drupal.org/node/222454 in that it is an HTTP fail. Server security could be an issue, but mysteriously enough the D6 CanPo is working great on the same shared environment.

Is there a work around to this technique? Both D7 versions are stopped by the server environment.

Cheers!

Hi,

For me it was caused because of twitter feeds on sidebar. I disabled that block and the error stopped showing up.

I am having the same issue.

It does eventually work after a few requests being sent for quotes.

Drupal: 7.9
uc_CanadaPost: 7.x 2.x dev (updated Dec 5 2011)
Ubercart: 7.x 3.0 rc2

In the logs at the same time i am getting errors:

Exception: String could not be parsed as XML in SimpleXMLElement->__construct() (line 365 of /home/simpl843/public_html/sites/all/modules/uc_canadapost/uc_canadapost.module).

Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 84: parser error : Premature end of data in tag shippingDate line 84 in _uc_canadapost_post_xml() (line 365 of /home/simpl843/public_html/sites/all/modules/uc_canadapost/uc_canadapost.module)

I only see fixes for version 6 not 7.

I do not have any twitter blocks on my page or even any modules to do with twitter on my site.

having the same issue with same setup as staulien...
For every time I calculate shipping I get 10 logged error messages. here''s 3 of them:

Exception: String could not be parsed as XML in SimpleXMLElement->__construct() (line 365 of /home/content/31/8593831/html/sites/all/modules/uc_canadapost/uc_canadapost.module).

Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in _uc_canadapost_post_xml() (line 365 of /home/content/31/8593831/html/sites/all/modules/uc_canadapost/uc_canadapost.module).

Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: 3.0 in _uc_canadapost_post_xml() (line 365 of /home/content/31/8593831/html/sites/all/modules/uc_canadapost/uc_canadapost.module).

is there any resolve to this?

I've now found tha\t it could be a server firewall issue or port issue.
When i ran everything locally and turned on port 30000 i found it worked great. so we're now moving our site to another hosting that allows for that port to be open etc...

Thank you Strawman I will contact my provider and see if they are blocking that port. If so this will be my 3rd time this year i have had to move providers for various reasons.

I have tested the connection from my service provider via a php script and it shows that there is no issues connecting to Canada Post's service.

The code i used to test with was:

$server = "sellonline.canadapost.ca";

$port = intval($_GET["port"]);

if (!$port) {
    $port = 30000;
}

echo "Connecting $server:$port<br/>";

$fp = @fsockopen($server, $port, $errno, $errstr, 30);

if ($fp) {
    echo 'Port '.$port.' is open, connected to '.$server.' OK!';
}
else {
    echo "Error: ".$errstr;
}

The message i get is:

Connecting sellonline.canadapost.ca:30000
Port 30000 is open, connected to sellonline.canadapost.ca OK!

This is very strange. I'm having the same problem too. Although for me, it is intermittent... perhaps 1 in 10 attempts fail. The thing is, when we are seeing errors along the lines of:

Exception: String could not be parsed as XML in SimpleXMLElement->__construct() (line 365 of /home/simpl843/public_html/sites/all/modules/uc_canadapost/uc_canadapost.module).

Warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 84: parser error : Premature end of data in tag shippingDate line 84 in _uc_canadapost_post_xml() (line 365 of /home/simpl843/public_html/sites/all/modules/uc_canadapost/uc_canadapost.module)

drupal_http_request thinks everything went fine. I added the following checks just prior to creating the simplexmlelement:

  if (isset($http_response->data)  && !isset($http_response->error) && ($http_response->code == 200 ) ) {

And the problem still occurs every once in a while. So indeed drupal_http_request thinks everything went fine.

So far I have two possibilities of how this can possibly occur:
-a problem within drupal_http_request where, strangely, it gives back the data, but sometimes (when you see this problem) the document is not actually complete. No errors are reported.

-canada post really is sending bad/incomplete responses sometimes.

Sorry, I have found no solutions yet.

I too have this problem... getting desperate as ready to go live and am only getting a quote maybe 2 times in every 10 tries (same logged errors - Notice: Undefined offset: 1 in drupal_http_request() (line 920 of /home/includes/common.inc). etc) and occasional ajax pane popup as described above.

I have a D6 UC2 version (different website) on same host,server and IP and no problems on that site. Hate to have to redesign it all in D6 but may have to.

I got rid of the ajax pane popup so as not to scare my users by putting the xml processing in a try-catch block. For me, the problem didn't happen so often, so I can live with it for now.

  try{
    $response = new SimpleXMLElement($http_response->data);
  }
  catch ( Exception $e) {
    return FALSE;
  }
  

Now when it does fail, the user is simply asked to try again.

Implemented the above, thanks.

Still successfully returning only 1 of 10-15 attempts to retrieve quotes.

Strange.

Provider confirms no traffic is being blocked, Canada post confirms requests from my account are being made and replies sent.

I wrote some SimpleTest test cases to try to reproduce this, and I find that I can reproduce a failure about 1 time in every 20 requests or so. When it fails, it's because the Canada Post server returns an incomplete, truncated XML document. SimpleXMLElement fails because it can't parse this incomplete document.

This DOES seem to be a problem with drupal_http_request(), as I can't reproduce the problem when I make the rate request from the command line using wget. Realistically, even if I figure out what the problem is in drupal_http_request(), there's no way a fix for this will be put into core Drupal 7.x or 6.x - it would affect too many things. And a patch for Druapl 8.x isn't needed because drupal_http_request has been replaced by Symfony.

So, what I did was to avoid HTTP altogether, and use a socket to connect directly with the Canada Post server and retrieve the quote. With the attached patch, I have been able to run the test cases over 1000 times without failure, so I believe this may finally be the solution.

To finish off this issue, I need people who see this error to apply the attached patch, test it, and report their results here. I'm especially interested in hearing from people like #11 who see a majority of failures with only a few scattered successes, because my tests with the unmodified version of this module show only a few scattered failures. If this works, I will backport the code to the Drupal 6.x version of this module.

Strange isnt it why some get lots of errors others dont?
I just tried again and got 9 successes, 4 failures and then success fail success etc
One thing, I dont know if its been mentioned before but when I get the fail its always a very quick result. I always know when its going to be successful because It takes much longer to complete.
I will implement your patch as soon as I get an opportunity (hopefully later today)

Edited as I made a silly mistake!!
Was confused by the display of xml data....
I had 'display debug information settings to administrators set to on' (strange I had not seen the debug info previously, must have been the first time logged in as admin).

So! Thanks a million TR the patch seems to have done the trick.

Sounds like you have checked the option to display debug messages, at admin/store/settings/quotes/settings ?

Your 100% Correct, had modified #14 before I read your response!

Patch from #12 works great for me also...
This is awesome!

Thanks so much TR - this patch was a life saver at Inmotionhosting.com. Not sure why but drupal_http_request was very intermittent here even though it worked perfectly at bluehost (albeit it on drupal 6). Even turned off modsec and no impact. Socket works perfectly.

Also note that AJAX form queries were being shut down by modsec and the user would get an error when updating the country field on the address form. Brutal. Turning it off solved this problem.

The patch is not fixing the issue for me. I am always seeing "There were problems getting a shipping quote. Please verify the delivery and product information and try again. If this does not resolve the issue, please call in to complete your order." The error no longer shows up in the logs, but there is still nothing displayed in the order page. Weird as it looks like the xml is returning properly:

SimpleXMLElement::__set_state(array(
   'ratesAndServicesResponse' => 
  SimpleXMLElement::__set_state(array(
     'statusCode' => '1',
     'statusMessage' => 'OK',
     'requestID' => '2453244',
     'handling' => '3.0',
     'language' => '0',
     'product' => 
    array (
      0 => 
      SimpleXMLElement::__set_state(array(
         '@attributes' => 
        array (
          'id' => '1020',
          'sequence' => '1',
        ),
         'name' => 'Expedited',
         'rate' => '6.89',
         'shippingDate' => '2013-02-21',
         'deliveryDate' => '2013-02-22',
         'deliveryDayOfWeek' => '6',
         'nextDayAM' => 'false',
         'packingID' => 'P_0',
      )),
      1 => 
      SimpleXMLElement::__set_state(array(
         '@attributes' => 
        array (
          'id' => '1010',
          'sequence' => '2',
        ),
         'name' => 'Regular',
         'rate' => '6.89',
         'shippingDate' => '2013-02-21',
         'deliveryDate' => '2013-02-25',
         'deliveryDayOfWeek' => '2',
         'nextDayAM' => 'false',
         'packingID' => 'P_0',
      )),
    ),
     'packing' => 
    SimpleXMLElement::__set_state(array(
       'packingID' => 'P_0',
       'box' => 
      SimpleXMLElement::__set_state(array(
         'name' => '1 item',
         'weight' => '0.5',
         'expediterWeight' => '0.5',
         'length' => '1.0',
         'width' => '1.0',
         'height' => '1.0',
         'packedItem' => 
        SimpleXMLElement::__set_state(array(
           'quantity' => '1',
           'description' => '1 item',
        )),
      )),
    )),
     'shippingOptions' => 
    SimpleXMLElement::__set_state(array(
       'insurance' => 'No',
       'deliveryConfirmation' => 'Yes',
       'signature' => 'No',
    )),
     'comment' => 
    SimpleXMLElement::__set_state(array(
    )),
  )),
))

@adamtyoung: I wouldn't expect this patch to do anything in your case, because this issue is not about "There were problems getting a shipping quote." - that's a typical Ubercart message that indicates there were no quotes *of any type* that could be applied to your order. The above quote shows Canada Post has only two services that can be used for your package: "Regular" and "Expedited". If neither of those is enabled in your Canada Post settings, then Ubercart won't have any quotes to show your customer. There are other causes too, but all this is discussed in many threads on ubercart.org and in the Ubercart issue queue on drupal.org. If you need further help please continue the discussion in one of those other threads.

I just noticed these problems re-occurring and discovered I had updated uc-canadapost on one of my sites to latest dev release 7.x-2.0+7-dev and it had removed the patch. Is this patch going to be added to the dev version?

I just noticed these problems re-occurring and discovered I had updated uc-canadapost on one of my sites to latest dev release 7.x-2.0+7-dev and it had removed the patch. Is this patch going to be added to the dev version?

Hey there,

I've run into a wall here and I'm wondering if someone can help? No matter what, the moment the Canada Post Shipping Module requests info after putting in the zip or postal code, it returns the attached error 100% of the time.

(text)
"An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /?q=system/ajax
StatusText: error
ResponseText:"

I've completed the following so you know where I am:

Confirmed my account settings within Canada Post and have double checked I'm set up right (CPC ID, etc.).
I have debug information to administrators unchecked.
My provider (Bluehost, in this case) has port 30000 open.

*I'm unsure if the patch that TR posted (#12) would be applicable still. (I'm running Drupal 7.22, current uc_canadapost). If it's still applicable, how do I apply the patch?

Any help here would be appreciated. Not sure if I'm missing something simple because I'm over-thinking, or what.

Generic HTTP 500 errors with AJAX occur for a lot of reasons in Drupal, most of which would be unrelated to this module. First, I'd certainly try this with a default theme to rule out problems caused by any custom theme you may be using.

The specific error addressed by the patch in #12 is "String could not be parsed as XML" - you do not seem to have that problem. But if you did then yes you should try the patch and see if it works for you.

To find out if there is a problem with your Canada Post configuration, turn on the shipping quotes debug information at /admin/store/settings/quotes/settings and post the output here.

Thanks for the reply.

The last one is:

Invalid form POST data (?q=system/ajax)

I also have a PHP error relating to the (Notice: Undefined index: form_build_id in ajax_get_form() (line 320 of...)

Error remains when I test in a default theme.

Just an update:

I'm currently looking into the cause here, but it looks as though the error only occurs when you type a city name into the field. I can fill in the rest of the customer information in ubercart, but alas, when putting the city name in, the moment the shipping calculator attempts to perform it's operation, the error (screenshot in my first post ^) occurs.

Reported in #2037385: Ubercart Ajax 500 Error Checkout Page it seems like uc_canadapost has an undeclared dependency on i18n module, or needs a module_exists() check:

[09-Jul-2013 09:06:58] PHP Fatal error: Call to undefined function i18n_get_lang() in /home3/thespoy5/public_html/modules/ubercart/uc_canadapost/uc_canadapost.module on line 279

Thanks for the help guys,

I do have the i18n module installed, before the ubercart installation. Is there something I should be looking for here specifically on my end?

uc_canadapost already has a module_exists() check. The i18n module changed the name of that function, and it was fixed in uc_canadapost a year ago by #1686802: undefined function i18n_get_lang() in line 278. So you must have a very old version of -dev if you're seeing this error. Please upgrade.

Note that comments #23 - #29 are unrelated to the original post and the topic of this issue.
So we're back to the patch in #12 as a proposed fix for the original issue.

Hi TR,

Everything is up-to-date in drupal and it's modules for me. Is there a place you'd rather me post for additional help?

Thanks,

Chris

Hi folks. I too am having issues with ajax error notification. I have tried pretty much everything to try and track this down and still struggling. I applied patch #12 as drupal_http_request() didn't work on KnownHost. And I thought everything was going fine. Then we did a modification and testing revealed the AJAX errors. I made all the usual simplifications to track down the problem on our test site including reverting to Garland as the theme and then removing colorbox from the checkout pages. Lots of testing does seem to indicate that the problem arises when the city field is entered although why that would be, I have no clue. There is also no log in any of the error logs except for Google Chrome which isn't too helpful. Please see enclosed. This one has me truly baffled. Any hints on how else to track this down. BTW, I should add that browsers do behave differently:

Chrome - alert and wait for customer input to clear error prior to loading next page.
Firefox - alert then clear alert and load next page
IE - just runs right over the error I guess as the customer sees nothing.

In all cases, when the address is entered correctly the shipping details are correctly received from Canada Post and checkout proceeds without problem. Except for the rather annoying dialog box.

You can see some further details in the screen shot.

Another clue has been uncovered. When the customer uses a Saved Address, the ajax error never seems to occur. This one is probably very tricky and evil.

Hi TR and Longwave, this is a bit of an issue for us. We'd be glad to contribute some development funding to help track this down. Let me know if that would work for you.

Problem solved - it appears

Had to go into admin/store/settings/checkout/ajax and ensure that there was only one trigger - saved addresses. Had another trigger - postal code and it appears to my inexperienced eye that if there are two triggers and you submit, they someone clash generating the error we were seeing.

This problem exists for sure with shipping methods Canada Post and Flat Rate. Reverted to Flat Rate shipping to isolate problem, i.e. was this a Canada Post module problem or something else. And it was something else as is now evident in hindsight.

I'm new in Drupal, but i've found out, that in common.inc file in drupal_http_request() function there is a part:

<?php
$info = stream_get_meta_data($fp);
$alive = !$info['eof'] && !$info['timed_out'];
$response = '';

while ($alive) {
    // Calculate how much time is left of the original timeout value.
    $timeout = $options['timeout'] - timer_read(__FUNCTION__) / 1000;
    if ($timeout <= 0) {
      $info['timed_out'] = TRUE;
      break;
    }
    stream_set_timeout($fp, floor($timeout), floor(1000000 * fmod($timeout, 1)));
    $chunk = fread($fp, 1024);
    $response .= $chunk;
    $info = stream_get_meta_data($fp);
    // Sometimes $chunk is 0 in the middle of the file.
    $alive = !$info['eof'] && !$info['timed_out'] && $chunk;
  }
?>

For me, sometimes $chunk gets value 0 from XML responce in the middle of the file (sometimes value is 0,5) and it is interpreted like FALSE in WHILE. So i've just changed condition for WHILE.

<?php
// I've changed this.
$alive = !$info['eof'] && !$info['timed_out'] && $chunk;
// On this.
$alive = !$info['eof'] && !$info['timed_out'];
?>

This fixed the problem for me.
If I do something wrong, please let me know

@diuss1987: drupal_http_request() is a core Drupal function, so the proper place to propose fixes to that function is in the core issue queue at https://drupal.org/project/issues/drupal

Regardless, I'm sure that there is almost no chance at all a change like this would be made in drupal_http_request() in core. Therefore, I suggest the expedient and more profitable course of action would be to test the patch in #12 and see if that fixes the issue for you, as that patch WILL be put into the uc_canadapost module next time I have a chance to work on it.

This has become a confusing and unfortunately frustrating issue.

Should patch 12 be committed?

Would it make sense to write an overriding while loop for the Canada Post module?

I've implemented the change that @diuss1987 suggested and am seeing the quotes showing up again.

Has anybody run into issues in removing the chunk variable from the alive check?