The user is experiencing an internal error when attempting to list files in their S3 storage via the Aspose Cloud API endpoint GET /v4.0/storage/folder, receiving a 304 Not Modified status and an opaque “internal error” message despite successful connection validation . This suggests the issue lies within the Aspose backend rather than S3 configuration or permissions.
There have been prior reports of S3-related issues in the Aspose forum, including timeout errors (502, 60s/100s) when accessing or uploading to S3-backed storage, indicating possible instability in the storage integration layer [3, 5]. One case involved a 301 redirect error from Amazon S3, where the bucket required a specific endpoint, suggesting potential routing or regional endpoint resolution problems in the Aspose backend . Additionally, during timeouts, Aspose has returned HTML responses instead of JSON, leading to parsing failures and generic internal error messages—this could explain the vague error the user is seeing .
Given these patterns, the current issue may stem from a backend timeout or misrouting when listing objects in the S3 bucket, particularly at the root path (/). While the connection test passes, actual file listing may trigger different code paths that are failing silently.
Recommended actions:
Try listing a subfolder (e.g., path=/some-subdir) to see if the issue is specific to root-level listing.
Confirm if the S3 bucket is in a non-standard region and ensure the correct endpoint is configured.
Monitor for any transient outages or delays, as similar issues have been reported intermittently.
Please let us know if the subfolder listing attempt succeeds or fails, as that will help isolate the root cause. We will escalate this internally to investigate potential backend regressions affecting the /storage/folder API for S3 integrations.
Have you made any fixes in the last few minutes? We’re now seeing font fetching succeed in our code, but the files are still not visible in the Aspose Dashboard.