Errors/Warnings when trying to checkout after Canada Post quote received?

I can't reproduce any of this, and I have never seen an invalid XML response from the Canada Post server, which is what your error messages imply. What version of PHP are you running? It's possible the implementation of SimpleXML has problems in older versions of PHP.

PHP 5.2.5 shouldn't be the problem. I use a similar version.

You can put uc_canadapost in either place. I usually use sites/all/modules but sites/all/modules/ubercart/contrib should work without a problem.

SimpleXML is a PHP extension that makes it easy to parse XML data. uc_canadapost sends a quote request to the Canada Post server in the form of an XML document, and receives a reply also in the form of an XML document. uc_canadapost then needs to extract the quote data from the returned XML, and for this it uses SimpleXML. I'm not blaming Canada Post - I'm just saying that the errors printed by SimpleXML, e.g. "String could not be parsed as XML", indicate that the XML document returned from the Canada Post server is malformed. I've never seen that happen before, while you say you're seeing it all the time. That's why I thought it likely that your version of PHP was old and contained a version of SimpleXML that didn't work right for the Canada Post quote relies. However, it looks like that is not the case.

Perhaps you can look in admin/reports/dblog and see if uc_canapost is reporting errors there - there should be a complete copy of the request and response XML in the log if the request failed.

But as I said, I can't reproduce 1), and I never see 2) or 3) under any conditions, even when just using "Regular Parcel", so it's pretty hard for me to debug what is happening for you. Maybe check your module settings carefully (CPC ID, etc.), and make sure all your products have weights. Also check you settings on your Canada Post account - maybe you have disabled Expedited on the CP side, for instance.

Hi,

I experience the same problem.

The sellonline account is the one by default in the module.

If i ask for a quote with an invalid postal code, nothing shows up.
Then when I click on any link, it crashes with the same screen posted earlier (warning: SimpleXMLElement)

Also, the markup function doesn't work. Whatever I use, be it percentage or multiplier, doesn't reflect in the quote price.

Hope that helps.

If i ask for a quote with an invalid postal code, nothing shows up.

That's the expected behavior. If Canada Post can't provide a quote for whatever reason, nothing shows up. This is how all the Ubercart shipping methods work.

Then when I click on any link, it crashes with the same screen posted earlier (warning: SimpleXMLElement)

Again, I can't reproduce this. If I enter an invalid postal code, using the default sellonline account, no errors are shown. Is your store address set properly? Can you provide the XML request sent to the Canada Post server and the XML response returned?

Also, the markup function doesn't work. Whatever I use, be it percentage or multiplier, doesn't reflect in the quote price.

This is a separate issue, and you will need to open a separate bug report. I just tested this functionality and it works properly for me. When you create your new bug report, please tell me what you are entering in the markup fields on the admin page.

Double checked to see where the module was installed.

I had it in /modules/ubercart instead of /sites/all/modules.

All works well now. My bad :(

Thank you for your awesome work!

Same issue here.

To reproduce I had to do some backs and forths - set incorrect Zip code then corrected it, clicked "Review order" before the quote was completely loaded.

There was a "String not closed" exception (see the attached image).

Looks like the problem happens when the response comes only partially - in this case SimpleXMLElement fails to parse it. Perhaps need to check whether the response is a valid string.

Here's the quote from the dblog:

Shipping failed. Request was: <?xml version="1.0" ?><eparcel><language>en</language><ratesAndServicesRequest><merchantCPCID>CPC_DEMO_XML</merchantCPCID><fromPostalCode>T5S2X7</fromPostalCode><turnAroundTime>24</turnAroundTime><itemsPrice>70</itemsPrice><lineItems><item><quantity>1</quantity><weight>1</weight><length>1</length><width>1</width><height>1</height><description>4 items</description><readyToShip /></item></lineItems><city>Charlottetown</city><provOrState>PE</provOrState><country>CA</country><postalCode>C1A4P3</postalCode></ratesAndServicesRequest></eparcel>, response was <?xml version="1.

Also in dblog I can see the same error as listed in the previous reply:

Shipping failed. Request was: <?xml version="1.0" ?><eparcel><language>en</language><ratesAndServicesRequest><merchantCPCID>CPC_DEMO_XML</merchantCPCID><fromPostalCode>T5S2X7</fromPostalCode><turnAroundTime>24</turnAroundTime><itemsPrice>70</itemsPrice><lineItems><item><quantity>1</quantity><weight>1</weight><length>1</length><width>1</width><height>1</height><description>4 items</description><readyToShip /></item></lineItems><city>Charlottetown</city><provOrState>PE</provOrState><country>CA</country><postalCode>@#C1A4P3</postalCode></ratesAndServicesRequest></eparcel>, response was <?xml version="1.0" ?> <!DOCTYPE eparcel [ <!ELEMENT eparcel (error)> <!ELEMENT error (statusCode,statusMessage*, requestID)> <!ELEMENT statusCode (#PCDATA)> <!ELEMENT statusMessage (#PCDATA)> <!ELEMENT requestID (#PCDATA)> ]> <eparcel> <error> <statusCode>-3001</statusCode> <statusMessage>Destination Postal Code/State Name/ Country is illegal. </statusMessage> <requestID>248464</requestID> </error> </eparcel> <!--END_OF_EPARCEL-->

I still can't reproduce this - it never happens on my site. But what I can do is catch the error and hide it from customers. I will implement that in the dev version in the next couple of days.

Same error. Here's my debug output.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 81: parser error : AttValue: ' expected in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: <product id="103 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 81: parser error : attributes construct error in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: <product id="103 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 81: parser error : Couldn't find end of Start Tag product line 81 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: <product id="103 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 81: parser error : Premature end of data in tag ratesAndServicesResponse line 65 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: <product id="103 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: Entity: line 81: parser error : Premature end of data in tag eparcel line 64 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: <product id="103 in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

# warning: SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /var/www/oldgoldboutique.com/htdocs/sites/all/modules/uc_canadapost/uc_canadapost.module on line 347.

Did we ever move forward on hiding this from customers? Judging by the post date of when you said that and the release date of the latest -dev , I would say the work around was never integrated.

PHP Version 5.2.6-3ubuntu4.1
SimpleXML Revision: 1.151.2.22.2.39

for all these simply looking for an easy work around you can hack function _uc_canadapost_do_request() in the uc_canadapost.module at line 374 and change

  if ($http_response->data) {
    $response = new SimpleXMLElement($http_response->data);

to

  if ($http_response->data) {
    $response = @new SimpleXMLElement($http_response->data);

notice the @ in front of the "new". This suppresses warnings in PHP.

Same issue on -rc6. Need to apply my fix to hide the error from end user.

edit: this isn't a core module ...so i guess my rc6 thing doesn't apply :D

Having just had this hit someone trying to complete a purchase, I added logging code at key points and now have an answer to the cause of the errors in point #3 of the original poster. Point #2 is likely a symptom of the same issue.

The errors occur because sometimes the data received from Canada Post gets prematurely truncated. Since the current implementation of uc_canadapost checks only header and status messages and does not check to make sure that the data received ends with "!--END_OF_EPARCEL--" (I've left out the <>, because this drupal comments system keeps parsing it as comments), _uc_canadapost_drupal_http_request() returns the bad data only to have it rejected at the $response = @new SimpleXMLElement($http_response->data) line.

The obvious solution is to check for proper stream termination and re-request if "!--END_OF_EPARCEL--" is missing.

Here's my solution (applied to uc_canadapost.module):

1. Changed the line:

$http_response = _uc_canadapost_drupal_http_request($url, $headers, 'POST', 'XMLRequest='. urlencode($xml));

to:

  for($attempts = 5; $attempts > 0; $attempts--) {
    $http_response = _uc_canadapost_drupal_http_request($url, $headers, 'POST', 'XMLRequest='. urlencode($xml));
    if ($http_response->data) break;
    sleep(5);
  }

2. Locate the lines:

  // Fetch response.
  $response = '';
  while (!feof($fp) && $chunk = fread($fp, 1024)) {
    $response .= $chunk;
  }
  fclose($fp);

And add the following immediately after it:

  $eos_pattern = '/<!--END_OF_EPARCEL-->/';
  $eos_offset = strlen($repsonse)-40;  //Want to start matching near end of string
  if(!preg_match($eos_pattern, $response, $eos_offset)) {
    $result->error = "ERR";
    return $result;
  }

As for why the steam is getting truncated prematurely in the first place, I'm not sure, but I wonder if there is a reliability problem with the condition, used to test end of data, in this block of code:

  while (!feof($fp) && $chunk = fread($fp, 1024)) {
    $response .= $chunk;
  }

If not, and it's a reliability problem with the network, I wonder if HTTP resume (if supported by the Canada Post server) could be an intermediate solution before retrying the whole transaction? Maybe that's getting overly complicated. :-)

Anyways, my code changes above have solved the problem for me.

The OP's Point #1 might be a configuration issue. Make sure you've enabled the shipping options you want both in your SellOnline account and on your Ubercart "Quote Methods" for Canada Post configuration page under "Home » Administer » Store administration » Configuration » Shipping quote settings."

TR: Could you please review and incorporate my changes somehow? I believe it should resolve this bug. Thanks.

*bump* Are the changes I recommended, and which fixes this bug, going to be incorporated or not?

Yes this has fixed my issues regarding the SimpleXMLElement errors as well. I can now view the "review order" stage and process my order.

Thanks quervo.

Having this exact problem, not every time but regularly. Looking at the CVS logs, it doesn't look like this was fixed. I've used quevo's code and so far I don't get those errors. Only done about a dozen tests so far.

I've created a patch for 1.0 as well as 1.x-dev in hopes that someone else can use them and/or it gets further review and committed if it's the right solution.

This does seem to stop the errors but it's still failing to retrieve quotes frequently, getting a "NULL" response sometimes, which I believe is from this patch. The request is failing after x tries setting the "ERR". Other times the log just says "false", for the response, which it often did before. (I'm exporting the XML request and response to watchdog).

I look forward to any further feedback or discussion on this issue.

Thanks!

It appears that if you don't have any checks on cp services in quote methods it won't display even if you get the response. This line :
if (isset($services[$id]) && ($services[$id] == $id)) {
in function
uc_canadapost_quote($products, $details)
prevents it. The array result from this call
$services = variable_get('uc_canadapost_services', _uc_canadapost_service_list());
always returns the list with 0 value.

I have this same problem and patch from post #15 will kind of fix it and now it wont get stuck to "Receiving quotes..." as it use to earlier, but it never gets quotes from Canada Post either, so it doesn't really solve my problem.

I did some testing and in my case most of the responses were truncated prematurely. maybe 1-2 out of 10 were successful . Obliviously this wasn't good enough for a production site as its not acceptable that shipping quote for Canada post is not shown (there is also pick up option..).

I don't really know PHP that well but I did following change.

while (!feof($fp) && $chunk = fread($fp, 1024)) {
    $response .= chunk;
  }

to

  while (!feof($fp)) {
    $response .= fread($fp, 1024);
  }

And at least for me it looks like all the request are returning right now. Did like 15 test and didn't see any broken responses anymore.

Can somebody with a bit more PHP experience take a look and comment if the change makes any sense.

On example 3 here: http://php.net/manual/en/function.fread.php suggests you should capture packets in chunks.
I guess that's why it was like that in the original code.

I implemented the changes in #15 and #22. This seems to have solved the problem.

The problem is with the Canada Post Server. In testing on xampp, it never come up. Only when I went live did I seem to have the problem.

I think #22 is right. The current code makes no sense - if fread() returns nothing (which is quite possible, even likely, when there are network delays) the current code aborts instead of blocking. Note, I didn't write that code, I inherited it when I adopted the module. I'll have to do some tests, but I'm pretty sure spylvas found the cause of this problem.

Wish I found this issue earlier, but I can confirm #22 is the source of the problem. I have fixed if by replacing the loop with a call to the php 5 stream_get_contents() function.

$response = stream_get_contents($fp);

I have also had the problems discussed in this thread. Followed #26 advice and so far so good. Thank you!

Followed the advice from #26. This fixed the SimpleXML errors I was getting as well.

I replaced:
while (!feof($fp) && $chunk = fread($fp, 1024)) {
$response .= chunk;
}

with:
$response = stream_get_contents($fp);

I already posted at http://drupal.org/node/929278#comment-3746910

if anyone can tell me which of the patches above is the right one, and if any of these are incorporated into the Nov 12 2010 release of Version 6.x-1.x, that would be much appreciated!

cheers
Fish

ok, i tried the patch from #26, i can verify that it clears up the issues i was having!

can we PLEASE have that put into the next release, so that others don't go through the same frustration? :-)

cheers
Fish

I just applied the change from #26 to a PHP5 server and it works perfectly.
Don't know if this module aims to be PHP4 compatible or not, but here's the patch anyway.

Came here after receiving the same XML errors. Verified that Patch #31 above fixes the problems for me!

My hesitation about making this change an official part of the module is this:

The "bad" code is actually an exact copy of the Drupal core function drupal_http_request(), with one bug fix not related to the "chunk" code that's causing this issue. That means the problem we're discussing here affects drupal_http_request() too. And there's my reason - this problem has been discussed in the Drupal core issue queue for many years, and solutions identical to #22 and #26 (and #28 and #31, which are the same as #26) have been proposed over the years. Those solutions have also caused problems, which is why the change has not been made in Drupal core.

I'm not too thrilled with the idea of simply swapping one set of problems for a different one. The current problem is "known" in the sense that we have this issue which documents the failures and provides some workarounds, so someone experiencing the issue can find and apply one of the above fixes. It's also limited in scope because the issue does not affect everyone, or even most people, who use this module - there's clearly still an unknown factor which determines who experiences the issue and who doesn't. I'm guessing something to do with PHP version, or server settings, or web-host-imposed configurations like open_basedir and the like.

The good news is that this seems to have been fixed in the latest -dev release of Drupal 7 core, so it should no longer be an issue for uc_canadapost 7.x-2.x. However, for Drupal 6, some people are going to continue to have the problem.

If you want to help get this resolved, please participate in #617126: drupal_http_request() fails

What's strange about this is that it's consistently reproducible for some, consistently non-reproducible for others. The website I was working on was pretty much ubercart and nothing else. What's the common element for those of us who can't get this to work? Server config issue? Canada Post config issue?

I appreciate if it's a core issue it should be fixed in core, but if we can help tackle the issue, all the better.

Fantastic!
I was getting this error myself and #15 & #22 fixed me right up.
Thanks everybody! Thanks for maintaining this great (and necessary) module!

Hi TR,

I'm getting the same problem. It just started about a month ago, though my sites (2) have been live for over 3 years. I honestly have no idea what changed on the sites or server to cause this. I've tried different versions of the module with the same results.

For all intents and purposes I'm a complete noob at at PHP (I'm not even sure if I know how to properly run a patch!). Any help/corrected versions would be most helpful.

Here is the message I'm getting,

Location: http://www.mysite.com/cart/checkout/shipping/quote
Referrer http://www.mysite.com/cart/checkout

Message SimpleXMLElement::__construct() [simplexmlelement.--construct]: ^ in /home/nancy35/public_html/jouets/modules/uc_canadapost/uc_canadapost.module on line 387.

Severity error
Hostname 99.239.9.56

The 6.x drupal_http_request() function was recently updated in core. This patch updates _uc_canadapost_drupal_http_request() to match (it also includes the fix from #183435: drupal_http_request and malformed responses).

edit: I just noticed that I forgot to change the issue number in the filename, patch still works though.

@iswilson: Thanks! Looks good. I would like some of the above posters to try out this patch and report whether it fixes the problem for them or not. One of the problems I have with this issue is that this never happens for me - I assume because the bad behaviour has something to do with a server or PHP configuration setting that has yet to be identified. So I have to rely on people who DO have this problem to TEST the patch and TELL ME whether it works for them.

@iswilson: Perhaps you could post a review in #183435: drupal_http_request and malformed responses and move it to RTBC to help get this into D6?

@TR This php noob finally figured out how to apply a patch. So far, so good. When I tested my system this morning immediately prior to applying the patch, I had a fatal error that crashed the system. However, after applying the patch, I've tried it out about 20 times and no errors (prior to that my error rate was about 1 in 2 to 1 in 3). I'm sorry that I am not knowledgeable enough to tell you what I suspect is the source of the problem.

@iwilson THANK YOU!!! You are a lifesaver!!! I was starting to wonder whether I would have to transfer my wife's retail site to another CMS.

Partyman

I committed #37, hopefully that fixes some of these problems.

If you continue to have these problems with the latest 6.x-1.x dev, feel free to reopen this issue. I have a very promising fix for 7.x-2.x (see #1221466: "An AJAX HTTP error occurred" when getting shipping quotes in 7.x-2.x-dev: ) that could be backported if we haven't seen the end of this in 6.x-1.x.

I am still not getting any response from the shipping quotes module. Is this related to #26? It is not malformed XML, just nothing at all.