Context chain:

• Set up staticfiles: https://github.com/openwrt/asu/blob/main/asu/main.py#L39
• staticfiles from fastio is forwarded to starlette: https://github.com/fastapi/fastapi/blob/master/fastapi/staticfiles.py
• starlette returns FileResponse: https://github.com/encode/starlette/blob/master/starlette/staticfiles.py#L178
• Which, if MediaType is None (which it possibly always is), guesses the content type: https://github.com/encode/starlette/blob/master/starlette/responses.py#L301-L302
  • Which is a bundled component: https://docs.python.org/3/library/mimetypes.html
• And, if python can't figure out the mimetype, it uses text/plain

All that is to say: ASU should probably register mimetypes.add_type("application/octet-stream", ".img").
Godbolt sample

@AliveDevil So mimetypes not recognizing ".img" is one thing - but in my example the file ending is ".gz". It seems guess_type reads the mime-types from system files, which maybe are missing in the docker image?

python:3.6.4-slim can not guess extension well

Check the godbolt output: Python can guess encoding and file type separately.
Any .X.Y file is checked against the encoding list of file extensions (i.e. gz, xz, bz2) - this is ignored and dropped by starlette.
So a .jpg.bz2 would be (application/jpeg, BZip).

Starlette only cares about the guessed type: in this case .img evaluates to None, which is then falled back to text/plain.

This could be fixed by editing the mime.types file, or just fixed in application code, which would be less error-prone for users.

So this would mean we have to do mimetypes.add_type for other File Extensions too.

I queried the firmware names and found the following non-duplicated list:

So because anyway ASU provides Firmware-Files always it should always set content-type: application/octet-stream.
But because the File Extensions are not a limited set, setting it with mimetypes.add_type() would be not reliable.

Maybe something along these lines?

class FirmwareFiles(StaticFiles):
    async def get_response(self, path: str, scope):
        response = await super().get_response(path, scope)
        response.headers["Content-Type"] = "application/octet-stream"
        return response

app.mount("/store", FirmwareFiles(directory=settings.public_path / "store"), name="store")

Hi, I love how you analyze the issue and come up with ideas. I'm currently a bit focused to spent my OpenWrt time on the APK migration so don't really do stuff for ASU. If you need anything specific, please ping me.

This is the current Caddyfile, maybe someone got an idea how to improve it?

(cors) {
	@cors_preflight method OPTIONS

	header {
		Access-Control-Allow-Origin "{header.origin}"
		Vary Origin
		Access-Control-Expose-Headers "Authorization"
		Access-Control-Allow-Credentials "true"
	}

	handle @cors_preflight {
		header {
			Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE"
			Access-Control-Max-Age "3600"
		}
		respond "" 204
	}
}

{
	auto_https disable_redirects
	preferred_chains {
		root_common_name "ISRG Root X1"
	}
}

asu-02.infra.openwrt.org asu-02.infra.openwrt.org:80 sysupgrade.openwrt.org sysupgrade.openwrt.org:80 {
	tls [email protected]
	root * /home/openwrt/store/
	file_server /store/* 
        import cors {header.origin}
	header Access-Control-Allow-Methods "POST, GET, OPTIONS"
	header Access-Control-Allow-Headers "*"
	header Access-Control-Allow-Origin "*"
	reverse_proxy * localhost:8000
	redir /api/overview /json/v1/overview.json
}

Can create a PR tomorrow (CET) with an improved staticfiles handler.

the bandaid solution would be Caddy handle-path on the /store-prefix to overwrite the content-type: https://caddyserver.com/docs/caddyfile/directives/handle_path