I'm experiencing a similar problem with actix-files 0.6.5 and Firefox. The browser fails to display an image when the server returns 206 Partial Content.

It's not easy to reproduce. I think Firefox adds the Range header only if previous attempt to load the resource was interrupted either by a page reload or due to a broken network connection.

I've managed to find a hack workaround:

use futures::future::FutureExt;
use actix_web::{dev::Service as _};

app.wrap_fn(|request, service| {
    let path = request.path().to_owned();

    service.call(request).map(move |response| {
        if path.contains("/static") {
            response.and_then(|mut response| {
                response.headers_mut().remove("Content-Encoding");
                Ok(response)
            })
        } else {
            response
        }
    })
});

I'm serving files from the /static directory so modify to fit your use case accordingly.

Per RFC 2616 (https://datatracker.ietf.org/doc/html/rfc2616#section-3.5), Content-Encoding: identity should never be used:

identity
The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header.

Actix is doing the wrong thing here, regardless of how any browser behaves or misbehaves. One could argue that Firefox should silently ignore Content-Encoding: identity instead of failing with an error, since RFC 2616 uses "SHOULD NOT" and not "MUST NOT", and refusing to even attempt to display the content to the user is not particularly helpful, but this is not relevant to Actix.

The most reliable way to reproduce this using Firefox is probably to have actix-files serve a video file, since actix-files serves media files with inline disposition by default. This isn't perfectly reliable, since some unknown factor causes Firefox to sometimes load the entire file in one request and sometimes stream it in pieces via Range, and caching isn't the cause of this, but when Firefox chooses to stream the file through multiple requests, each request fails with NS_ERROR_INVALID_CONTENT_ENCODING. Firefox actually retries these requests aggressively in my case, maxing out a CPU core in the process, but every one fails.

actix-files reliably serves responses with the incorrect Content-Encoding: identity header to any request with both a valid Range header and an Accept-Encoding header, even an empty Accept-Encoding header. This is easy to verify using curl, netcat, or any other means of sending manual HTTP requests.

[package]
name = "example"
version = "0.1.0"
edition = "2021"

[dependencies]
actix-web = "=4.5.1"
actix-files = "=0.6.5"

use actix_files::NamedFile;
use actix_web::{get, Responder};

#[get("/")]
async fn index() -> impl Responder {
    NamedFile::open("test_file")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    use actix_web::{App, HttpServer};

    HttpServer::new(|| App::new().service(index))
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
}

#!/bin/bash

echo foo > test_file
cargo b
cargo r&
sleep 1
nc 127.0.0.1 8080 << EOF
GET / HTTP/1.1
Range: bytes=0-
Accept-Encoding:

EOF
kill %1

I've made a following workaround:

struct CustomFileResponder {
    file: NamedFile,
}

impl CustomFileResponder {
    fn new(file: NamedFile) -> Self {
        Self { file }
    }
}

impl Responder for CustomFileResponder {
    type Body = BoxBody;

    fn respond_to(self, req: &HttpRequest) -> HttpResponse<Self::Body> {
        let mut response = self.file.respond_to(req);

        // Modify the headers as needed
        let headers = response.headers_mut();
        if let Some(header) = headers.get_mut(actix_web::http::header::CONTENT_ENCODING) {
            if let Ok(h) = header.to_str() {
                if h == "identity" {
                    headers.remove(actix_web::http::header::CONTENT_ENCODING);
                }
            }
        }

        response
    }
}

And where you serve the file you make:

// Return the file as a response
let file = NamedFile::open_async(file_path).await?;
Ok(CustomFileResponder::new(file))

Now all .mp4 files served inline are opening flawlessly. But without this workaround they either get in a loop of errors or just give an error about wrong content encoding.