Script Development / Responding to Large Data DFF.RESP_LARGE_DATA
When returning MB-level or larger content, using return directly increases the overhead of JSON serialization, Redis message queue, and internal network communication. DFF.RESP_LARGE_DATA(...) writes the content to a temporary file and returns it as a file response, avoiding passing the complete value in internal messages.
Parameters
| Parameter | Type | Required / Default | Description |
|---|---|---|---|
data |
str / dict / list / tuple | Required | Large text or JSON-serializable data |
content_type |
str | Auto-inferred | Dict, list, and tuple default to json; other types default to txt; can also be explicitly specified |
| Example | |
|---|---|
1 2 3 | |
All Web services and Workers must access the same resource storage
This method relies on the shared resource directory. In high-availability or multi-Worker deployments, ensure that the resource directory configuration and mounts are consistent.
Non-string data must be JSON-serializable. Binary data should first be written to the resource directory, then returned using DFF.RESP_FILE(...).
content_type should use fixed short labels, such as json, txt, or html; do not pass MIME strings, path text, or values from requests.
A positive value for DFF.API(cache_result=...) may retain the generated response for cache reuse; when caching is not enabled, the temporary file is deleted after the response is sent. Script should not depend on the temporary file name or retention time. Small data should be returned directly with return; use this method only in large-data scenarios.