I’m developing a new plugin that imports JSON data from external sources. I’m trying to use the CORS proxy Datocms provided for our Translate plugin, but I’m getting unexpected responses from GET requests.
The response I receive is (�/�H�F&s&��l�P�R�"�ۇ-u��…etc etc etc. I’ve reviewed this with other developers and we believe the issue is with the proxy.
That looks like an encoding error. Where is the proxy trying to fetch from, and what is the data type supposed to be? Is it a binary asset of some sort, or possibly gzipped/brotli-ed?
In your code, it looks like the remote data source would normally be user-configurable, but do you have an example URL that shows this behavior?
Would it be possible for you to make a minimal example, please, either a hardcoded plugin tied to a specific remote URL that shows this behavior, or even just a curl command?
If it contains anything private (auth keys, etc.), please feel free to either DM me here on the forum or email the details to support@datocms.com.
Once I can reproduce the error, I can further investigate and report the issue.
The URL is configurable, yes. The idea for the plugin is that you can fetch JSON data from any API as long as it returns JSON. For use cases like if you have a products API and you would like to display a set of products. You can search and add items.
I have a test project in which I could give you access with all necessary settings set. You’d have to run the plugin locally. Go to the test model. Click on one of the search boxes and type something. This will trigger requests.
I have some test APIs which I’m using with a search string:
Thank you for the details! I was able to replicate and report the issue.
This was indeed a bug on our end in how we handled certain types of compression, especially zstd. We believe the bug should be fixed now. Could you please try again and let us know if you’re still seeing issues? (EDIT: We had to temporarily roll back this fix for the time being. Please see below.)
So sorry, we had to temporarily roll back this fix (it was causing issues with some other use cases).
We have to take another look and make sure we can fix it properly the next time. Sorry about that! We’ll let you know once it’s properly fixed the second time around…
We believe we fixed it properly this time, and hopefully without breaking the other use cases… please give it another try
Sorry, it was a bit difficult to get this right because it’s a serverless proxy that’s not easy to debug, and with all the cloud abstractions, it was a bit hard to see what it was actually doing to the traffic at each step. But hopefully we got it right this time. Please let us know if you still run into issues!
