Hello,
I am facing a 403 error generated by CloudFront when calling any Aggregate or server-side request from a specific ODC screen as shown below.
After investigating, it seems that the issue is related to the request payload size. In ODC, when an Aggregate is executed, the request payload includes all screen variables, even if the Aggregate itself does not directly use them all. In my case, one of the screen variables contains HTML content edited on the client side. This HTML text can reach around 100 KB.
When this screen variable is small, the Aggregates and server actions work correctly. However, once the HTML content becomes large enough, any request from that screen fails immediately with a 403 error. It appears that the request is being blocked or interrupted by CloudFront before reaching the server, because the ODC Portal shows the error but no server-side traces are generated.
The screen variable stores editable HTML content from an editor. On the database side, I am saving this content as Binary Data. However, on the client side, I need to keep it as Text so the user can continue editing it in the HTML editor.
As a workaround, I converted the HTML text to Binary Data on the client side using the JavaScript btoa() function when saving/retrieving the HTML content from the server side. This helped avoid passing the raw large HTML text directly in the request payload.
Could you please confirm whether this behavior is expected in ODC due to CloudFront/request payload limitations, and whether there is a recommended approach to handle large editable HTML content stored in screen variables? Is there any way to disable this?
Thank you.
Yes, this behavior is expected in ODC because screen requests can include all screen variables in the payload, and large payloads may be blocked by CloudFront before reaching the server. Since the HTML content is stored as a large Text variable, it increases the request size significantly. Your workaround of converting the content to Binary/Base64 is a valid approach to reduce issues with raw HTML payloads. Currently, there is no option to disable this behavior, so the recommended approach is to avoid keeping large editable content in screen variables and instead load/save it separately when needed.