UPS API Address change

What do you mean by "eliminated all issues"? Ideally that would imply that every single UPS related issue in the queue would be fixed by this, but I don't think that's the case somehow!

Also this should be a task, unless UPS have suddenly changed their API address and the old one no longer works, and "needs review" only applies when there is a patch to test.

What issues were you seeing that were fixed by this change? I'm surprised that only one person has reported this if the old address is no longer valid (which doesn't seem to be the case anyway, as it still returns results if I visit it in a web browser)

From the RateWS.wsdl file, in the Rates_Pkg_Gnd.zip file which contains the API documentation from UPS (https://www.ups.com/gec/techdocs/pdf/Rates_Pkg_Gnd.zip)

	<wsdl:service name="RateService">
		<wsdl:port name="RatePort" binding="tns:RateBinding">
			<!-- Production URL -->
			<!-- <soap:address location="https://onlinetools.ups.com/webservices/Rate"/> -->
			<!-- CIE (Customer Integration Environment) URL -->
			<soap:address location="https://wwwcie.ups.com/webservices/Rate"/>
		</wsdl:port>
	</wsdl:service>

I'm reading that as the wwwcie.ups.com address is for testing/non-production use. This (should?) also affect 7.x as well.

Assigning to TR to see if he knows anything about this.

@LiveWire: To be very clear, the URLs currently used by Ubercart work and are not the cause of any known problems or issues.

@daroz: Ubercart doesn't use the UPS SOAP web service, it uses the XML method, so the contents of the .wsdl file aren't relevant.

Ubercart currently uses:
https://wwwcie.ups.com/ups.app/xml/ for the Testing server and
https://www.ups.com/ups.app/xml/ for the Production server.

(The service type gets appended to these URLs, e.g. 'Rate' is appended when using the Rating API)

As I said, these both work.

The current UPS documentation isn't consistent. Some of the UPS documentation (but none of the example code) recommends using https://onlinetools.ups.com/ups.app/xml/ for the Rate and Ship APIs when in Production mode. But it also recommends using https://wwwcie.ups.com/ups.app/xml/ for the Track API and makes no distinction between testing and production modes. And only some of the example code shows a URL, and the only URL found in the example code is https://wwwcie.ups.com/ups.app/xml/.

So it's unclear to me whether UPS is actually changing from www.ups.com to onlinetools.ups.com, whether they're both equivalent, or whether one or both is a legacy URL. Both work. I am currently trading e-mails with UPS tech support on this matter (it's outside the scope of the level 1 support on the telephone, so they're having me communicate with level 2 via e-mail.) When I get a definitive response I'll roll a patch if necessary.

Moving to 7.x-3.x, because that's where it needs to be addressed first.

Here's a patch if you want to try it out in the meantime.

In #7, The testing server link leads to "Page not found." On a production site, we use Testing because our orders get shipped through a fulfillment agency.

The patch looks like it won't fix the Testing Server. "Click to Calculate shipping" was returning a message to check delivery and product information until I updated the address. To fix the issue for my site, I followed instructions to update the link here: http://www.ubercart.org/forum/support/17670/ups_module_not_getting_shipp...

So you're saying https://wwwcie.ups.com/ups.app/xml/Rate returns 404 for you? (note that the link in #7 needs the service type appending, which is Rate in this case)

My mistake -- using only https://onlinetools.ups.com/ups.app/xml/ would return 404. The link you give me works of course, in my browser. In my Ubercart setup, onlinteools.ups.com seems to work when wwwcie.ups.com was not. The client wanted the issue fixed immediately, so I didn't have time to debug it further than that. If no one else chimes in, I can attempt to do some more thorough testing.

onlinetools.ups.com is the proposed new production, wwwcie.ups.com is the old and current testing. If you're saying that the *testing* URL isn't working in testing mode, then that's a completely different issue that no-one has ever mentioned before. And if clicking on the link in #10 returns the following result, then I don't see how it's possible that testing mode doesn't work for you:

Service Name: Rate
Remote User: null
Server Port: 443
Server Name: wwwcie.ups.com
Servlet Path: /Rate

Committed patch to 7.x-3.x and 6.x-2.x.

This didn't seem to make it to the 6.x branch.

Forgot to push.