Bug In Postalmethods Api Causing A 400 Bad Request

[NETLINK]

There's a bug either in the PostalMethods API or in the InvoiceDelivery class that's causing PostalMethods to return a 400 Bad Request respsonse header with 0-length response body.

 

It took me a long time to figure out, because Blesta wasn't returning an error message, just a "-1" error code, which is obviously meaningless, and nothing being logged.

 

I eventually got myself the response code from the Http curl wrapper class, which came back with "400".

 

I then extracted the $xml as string from the PostalMethods class before it was sent, and I did a manual post request to PostalMethods directly.

 

It came back with the following response:

HTTP/1.1 400 Bad Request
Date: Tue, 12 Apr 2016 19:17:05 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Length: 0

It turned out that the cause was an ampersand (&) in the company name:

 

<Company>Example & Co. Accountants</Company>

 

So, I'm guessing, the data is not being properly encoded, at least for the Company element.

 

 

[NETLINK]

It would also be nice to have the a log for this. Something that at least checks the response header. Maybe a general log for curl requests?

[NETLINK]

Adding hmtlentities() to line 384 in components/delivery/postal_methods/postal_methods.php as follows seems to have fixed my specific issue:

$address_xml .= "<" . $key . ">" . htmlentities( $value, ENT_XML1 | ENT_DISALLOWED ) . "</" . $key . ">\n";

[Tyson]

Thanks for the report. This is fixed in CORE-2178 for v4.0.