The asset delivery API randomly delivers gzipped data and non-gzipped data, regardless of your headers regarding compression.
Side note: The Content-Type header indicates that Roblox is sending application/octet-stream, when it is actually sending XML.
Expected behavior
The asset delivery API should respect the Accept-Encoding header.
Forgive me if this is under the wrong category, but I figured it should get to the right team anyway.
Hi Jack, Please could you share the url you are trying to call on assetdelivery API and how you’re calling it?
What you are expecting as a response and what you are getting back ?
https;//assetdelivery.roblox.com/v1/asset and the CDN link returned by https;//assetdelivery.roblox.com/v2/asset both seem to randomly return gzipped and non-gzipped content based on asset ID.
I can confirm this happens on https://assetdelivery.roblox.com/v1/asset even when setting the Accept-Encoding request header to identity, which according to spec should disable any kind of compression from the server.
At random, sometimes the server returns an uncompressed body, and sometimes it sends a gzip compressed body, and when this happens a response header Content-Encoding: gzip is correctly set.
Important: I’ve noticed that whenever the response is gzip compressed, it is accompanied by another header, X-Cache: Miss from cloudfront or X-Cache: Hit from cloudfront. I’ve also noticed that when the response is not compressed, the rbx-cdn-provider header is set to ak instead of aws.
I’ve only used this endpoint for decals, which is where I’ve encountered this issue. For example, GET https://assetdelivery.roblox.com/v1/asset/?id=118316249145279.