actix / actix/actix-web

feat/fix: Improved or customizable filetype detection for actix-files

Open
#4,134 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
24.8k
Forks
1.9k
Avg merge
23h 10m
Merged PRs (30d)
26

Description

actix_files [currently detects mimetypes using mime_guess](https://github.com/actix/actix-web/blob/c6249cc00c757083ae1b29a3c4e1748185f43071/actix-files/src/named.rs#L107-L125), which [explicitly](https://docs.rs/mime_guess/2.0.5/mime_guess/) reads only the file extension to determine the type. actix-files then uses a small set of types to determine the disposition.

The issue: common developer file types (Dockerfile, Cargo.lock, more) aren't recognized by mime_guess, so the `disposition: attachment` causes browsers to download them instead of display them.

---

There are several possible fixes/improvements, depending on how you look at it:

- zero config: A simple win (with a likely small perf impact) would be to additionally analyze files that `mime_guess` doesn't recognize (and which are therefore labeled `application/octet-stream`) using the git algorithm (load the first 8KB, check if that 8KB both has zero NULL bytes and is valid UTF-8) and if it appears to be text, change the mime type back to `text/plain` and `content-disposition: inline`.
- add a config or policy argument: adding another which allows users to provide a callback or something which would allow them to take this perf on themselves (and additionally for example state that type `application/pdf` should be inline) would be more flexible at the cost of larger API surface.

Would you be open to a PR implementing either or both of those? Or do you have other ideas for ways to improve the situation?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.