Re: --max-filesize and --compressed

> Am 02.03.2026 um 12:38 schrieb Andreas Mohr via curl-users <[email protected]>:
> 
> On Mon, Mar 02, 2026 at 09:53:34AM +0100, Daniel Stenberg via curl-users wrote:
>> Would it make sense to have some kind of limit to the "explosion factor" ?
> 
> Ah, indeed, possibly.
> An "explosion factor" config state seems to be
> much more precision-related *) than
> a raw result file size config state.
> (since the actually hurting most relevant characteristic
> of a compression bomb is
> the *very abnormally* high explosion factor vs.
> its tiny origin data, and especially vs.
> plain "normal" decompression examples).
> 
> *)
> - quite reliably catches compression bombs
> - is more future-proof than
>  enacting some raw fixed file size limit (vs.
>  eternally growing capabilities of systems!)
> 
> 
> OTOH with an input file of
> say 1GB and explosion factor limit of
> only 100 **), one would still end up with
> a dangerously large 100GB file size...
> 
> **) which might be already too low for
> many legitimate decompression activities
> 
> So, do instead resort to
> a plain file-size-based limit after all?

Do not forget the various use cases where the output is piped somewhere or immediately consumed by a libcurl application. If one pipes a WebSocket connection to some event processing, a limit might do more harm than good.

Regards,
Stefan

> 
> Greetings
> 
> Andreas Mohr
> -- 
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
> Etiquette:   https://curl.se/mail/etiquette.html

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html