Issues with unicode characters in XML
nauger opened this issue · comments
I haven't been able to dive in, but we've seen a few issues with parsing the response data from Braintree. I added some additional logging, and it looks like the custom XML parsing is failing on:
<payer-first-name>José</payer-first-name>
<payer-last-name>Smith</payer-last-name>
To add a bit more tracing, here, the parser receives that payer-first-name field as a list:
[{:xmlText, ["payer-first-name": 20, paypal: 106, transaction: 1], 1, [], 'Jos',
:text},
{:xmlText, ["payer-first-name": 20, paypal: 106, transaction: 1], 2, [], [233],
:text}]
It's certainly easy to reproduce. I have a separate project where I've been using fast_xml for parsing instead, and it handles the HTML entities just fine. I'll port it over soon, busy with a few other things currently.
Thanks! My current branch where I've fixed two issues with XML handling:
https://github.com/revzilla/braintree-elixir/commits/dont-gzip-for-now
The last gotcha we've noticed, is that some requests will fail with {:error, ":closed"} which seems to be an HTTPoison/Hackney issue when a pooled connection has been close. Not sure if a re-try mechanism is available further down the stack, of if you had any thoughts about that.
@nauger I've pushed up support for entity encoding and decoding, which seems to work as far as the tests show. Please test it out and let me know how it goes. If this solves the problem I'll release a new version.
@sorentwo Thanks! We'll test shortly. I know this isn't an issue with your library, but have you noticed {:error, ":closed"} in your apps too?
Not sure if it's Braintree about being more aggressive about closing sockets, or Hackney keeping them open longer? I'm just not sure where to dive in on that one.
Sorry, I haven't seen that one so far. I've seen failures while testing due to how Braintree rate limits certain calls (using the same card repeatedly, etc), but that's it.