Canada Post server change

[s_mack]

If you can believe it, they made the change without telling anyone...


But anyone using the CanadaPost shipping module will have to change their settings. As of last Monday, they switched (finally) to a DNS system. Either method worked through the week, but as of today they changed their IP (again, without telling their customers).

Instead of using 216.191.36.73 for the production server, you must now use: sellonline.canadapost.ca

Port is the same: 30000


I'll try to make the minor change to the contrib and re-upload to the downloads section.

- Steven

[s_mack]

I downloaded the latest contrib (version 1.3.7) from the downloads section and made the changes and re-uploaded as version 1.3.7.1

There are NO functional differences! If you have version 1.3.7 (of the CanadaPost contrib) then there is no need for you to upgrade... simply log into your admin->Modules->Shipping and change the server from the ip address to sellonline.canadapost.ca and you're done.

The only changes I made were some clarifications in the readme file and the admin instructions... and changed the default address to sellonline.canadapost.ca

- Steven

[Ajeh]

Thanks for the update ... this is always a help to others when unexpected surprises happen ...

[s_mack]

My pleasure.

I find it incredible that CP would make a change like this without alerting their customers. The only reason I found out was I had a slew of customer complaints that they couldn't checkout. When I tried myself, sure enough the shipping module was failing. I phoned CP and they said they decided to make the change on Monday. When I asked why I wasn't told... he gave me a "pass the buck" response about it not being his job to alert everyone and wasn't sure who was responsible.

In any event, I advise all Canadian shop owners using this module to make the change ASAP!


One thing... I noticed it slows the checkout process tremendously Since making the change, it now takes up to 10 seconds or more to get a return from the CP servers instead of less than a second previously.

I imagine you could use IP addresses still, but you'll have to keep up with the one they are using. At this moment, it seems to be 66.110.6.131 but that could change in a minute, an hour... a year or never.

- Steven

[s_mack]

FYI - I just tested...

using the domain name, it took an average 7.5 seconds (on 10 tries) to get the response from CP.

using the IP address, it took an average of 1.3 seconds.

- Steven

[Ajeh]

Lovely ... makes me want to move up north ...

[s_mack]

which gets me to thinking...

I wonder if there could be some way to re-write the module so that it detects the IP the first time it is accessed (using the domain) and that IP is stored. Then that IP is used instead up until an error occurs, and then the system would auto-check the IP again and use that one, etc.

Just a thought.

- Steven

[DrByte]

It's probably prudent to test the module on another server which uses a different NS lookup server to resolve the name to the IP address ... just to rule out whether the slowness is a result of your own webserver's access to NS services or otherwise.

Yes, one could probably rewrite to set a session variable the first time it successfully looks up an IP and is able to communicate ... but really it would be better if the hosting server was better tuned and maybe even cached its own NS lookup data etc.

On second thought, the session variable approach probably wouldn't benefit all that much, since session details are customer-specific. So, it would help a customer if they were making several visits to the shipping or estimator pages, but that's all.

So, recoding would require storing the last-resolved date and the IP used at that time. Then set a "check" interval. And if a failure occurs when attempting to access (which likely will cause a 30-second timeout), then a new attempt to resolve would have to be initiated ... all while the customer is waiting ...

... hence the suggestion that the server is the place to fix an NS lookup problem, rather than code ...

[DrByte]

BTW - thanks for researching and posting the update.
I've seen a couple posts about the change this week, but haven't had time to investigate.

[s_mack]

No problem at all DrB.

Thanks for the suggestion re: host ns lookup. that didn't occur to me that it could be my host's issue. I just figured it made sense that it would be slower since there is an extra step, but I'll email the help desk and see what they can do.

- Steven