I’m trying to upgrade on 1.2.165 from 1.2.161 (after critical fails with 1.2.162, 1.2.163 and 1.2.164). And i found again new critical (for us) bug:
Every call to http.request with POST method and payload size over 16kb fails with status code -1000 and message in log
WARNING:DLIB: Unhandled ssl status code: 16384 ( 4000)
Can you fix it?
And i have one optional question:
Do Defold team do regression or any tests for every release?
We have a lot of unit tests but these tests do not cover every aspect of every API. We also test every release using a couple of different test apps. And we usually test Blossom Blast Saga with the latest release.
Your error happens with HTTPS POST requests right? I assume that normal HTTP POST requests work?
I believe their is a 2^14 record length limit for TLS. If you need to send more data I think it needs to be sent chunked (which we do not support).
Yep. This error happens with HTTPS POST requests.
There is no (visible) limits for body size in defold 1.2.161. But you break the back compatibility without notice after 1.2.162. And i don’t see any information about this limitation in documentation. This two things are bad for production-ready game engine.
Defold 1.2.162
We’ve replaced the internal SSL library to mbedTls, and thehttp.request()can now work with a lot more secure sites, including Playfab
In the 1.2.162 Release, we moved from using axTls to mbedTls for supporting https requests towards sites with more modern handshakes. I very much suspect this change to be the cause of this issue.
It is always unfortunate when we happen to break some functionality that has worked previously.
But sometimes it happens, and we’re sorry about that.
In this instance, it was a feature we didn’t know the library had, and we didn’t have a test for it (since it came with the library). Also, it is the reason it wasn’t specifically documented.
I can agree that we can do better in terms of communication, and with the new release process we hope to be able to, with the help of our power users, test a new BETA release’s features before they get published.
As for a proper fix, we’ll look into it, but I currently have no ETA.
As for a workaround, you can try to send via HTTP instead (if possible).
We have now released the latest BETA, with a fix for this issue.
Would you please test this beta version and confirm if this fix works for you?