actix / actix/actix-web

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

Abierto
#4,134 0 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Rust
Estrellas
24.8k
Forks
1.9k
Merge medio
23 h 10 min
PR fusionados (30 d)
26

Descripción

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?

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.