Overwrite FileResponse Content-Type with application/octet-stream for all files in /store

[AliveDevil]

Fixes #1059

[AliveDevil]

Should these be squashed? @aparcar

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 73.33333% with 4 lines in your changes missing coverage. Please review.

Project coverage is 90.47%. Comparing base (5e65dec) to head (122d701). Report is 141 commits behind head on main.

Files with missing lines	Patch %	Lines
asu/fastapi/StaticFiles.py	69.23%	4 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1064      +/-   ##
==========================================
+ Coverage   80.75%   90.47%   +9.71%     
==========================================
  Files          15       15              
  Lines         977     1123     +146     
==========================================
+ Hits          789     1016     +227     
+ Misses        188      107      -81     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[aparcar]

Could you please try again and see if the issue is resolved? If so the Caddy docs are broken, caddy is broken or I misunderstand some stuff, however it worked on my test run with Firefox

[0nelight]

A caddy team-member said: "Your upstream app should set a correct Content-Type header."

https://caddy.community/t/caddy-reverse-proxy-sets-content-type/15604/2

This PR looks good from my point of view, but I have no development setup here so I didn't test it.

[aparcar]

This is now fixed by letting Caddy server serving the /store/ path. Caddy automatically determines the right header types and this issue should be gone.

[aparcar]

I think I solved this slightly simpler, could you please have a look at https://github.com/openwrt/asu/pull/1462?

[0nelight]

Yes, exactly! I think #1462 is a more compact, solid and DRY solution 😊

[aparcar]

Superseded via #1462