file-type

Description In #768, was changed to following an RFC draft. However, that draft has not entered a standard track, let alone exit its draft state, and it was created in 2019. It's still being updated, so it may eventually become standard, but until that time it would be best to maintain for compatibility. GitHub search shows exceedingly low support for , while the traditional shows overwhelming use. Existing Issue Check [x] I have searched the existing issues and could not find any related to my problem. File-Type Scope Acknowledgment [x] I understand that file-type detects binary file types and not text or other formats.

Lets applications bound read-buffer allocations driven by untrusted file content, helping prevent excessive memory allocation (CWE-789) while preserving custom-detector compatibility by default. Exposes the opt-in limit introduced in strtok3 v10.4.0 for read-buffer allocations and stream lookahead, defaulting to . Rejects oversized requests with , preserving the fallback during gzip content probing. Resolves the custom-detector compatibility issue caused by sharing ZIP’s 1 MiB allocation limit, keeping the two limits independent.

Update to and use its configurable decompression limit when inspecting ZIP metadata entries. Decompression size checks, cancellation, and trailing-data recovery now live in @tokenizer/inflate, allowing file-type to remove its own decompression implementation. File-type retains its ZIP iteration override to enforce archive-wide scanning budgets, entry-count limits, and descriptor-size validation without changing the dependency’s behavior for other consumers. Handle entries that exceed the limits gracefully and preserve detection when a ZIP data descriptor is incomplete or has no signature. The upstream inflater recovers decompressed metadata when descriptor bytes remain after the deflate stream. Resolves Borewit/tokenizer-inflate#165 Related to https://github.com/Borewit/tokenizer-inflate/pull/213 #807