-
It should be made clear in the manual how Deno internally handles automatic body compression:
If Deno does not maintain a cache, it could be inefficient for servers with high traffic to compress bodies upon every request, especially during a denial-of-service attack. If Deno does maintain a cache, it is not specified how long cache entries last, and long-lived servers may end up keeping cache entries that are no longer needed. A potential solution would be to specify that Deno does indeed utilize a cache, and to provide a Deno API to inspect/remove entries from such a cache. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
It does not maintain a cache. It would a) be inefficient and b) break the model of the request being handled by the userland code. The userland code would be significantly slower in a DDOS situation anyway, versus a per response compression. If we were to implement response caching, it would align to the web platform APIs of |
Beta Was this translation helpful? Give feedback.
It does not maintain a cache. It would a) be inefficient and b) break the model of the request being handled by the userland code.
The userland code would be significantly slower in a DDOS situation anyway, versus a per response compression.
If we were to implement response caching, it would align to the web platform APIs of
Cache
andCacheStorage
and in those cases we could in theory sideload a compressed body in the response when a cached response was used. In those cases it would be up to the userland code to determine if the cached response is used or not anyway.