files in cloud are opening in browser instead of downloading about dfp_external_storage

[khoran]

Thanks for the pointers. Turns out it's not a problem in this project, but the content_type value in the file method of dfp_external_storage.py was getting set to None. This was because the mimtypes library relies on the presence of certain system files to define the actual mime types. In the production docker images, these files were not present. As soon as I added the package media-types to the container, then everything worked fine. I will raise and issue on frappe-docker.

[developmentforpeople]

Hi @khoran , thanks! I have no updated Frappe yet. Could you compare both cases headers sent by server? Seems some new header added/removed with new version :) If not I will try to check asap. If you find differences, it can be easy searching for the header within frappe and dfp_external_storage apps to locate the code implied and maybe we cold fix together ;)
I will try to check it within my holidays in two weeks. Thanks for using the app and take your time to write this bug with all info possible 👍 Have a good day @khoran !

[khoran]

I recall that the one showing up in the browser always had the mime type set to text/plain. So I think that is the cause of the problem.

[khoran]

Headers from working version:

HTTP/1.1 200 OK
Server: Werkzeug/2.2.2 Python/3.10.5
Date: Mon, 10 Jul 2023 14:30:52 GMT
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Content-Length: 61044
Set-Cookie: sid=7...; Expires=Thu, 13 Jul 2023 14:30:52 GMT; HttpOnly; Path=/; SameSite=Lax
Set-Cookie: system_user=yes; Path=/; SameSite=Lax
Set-Cookie: full_name=Administrator; Path=/; SameSite=Lax
Set-Cookie: user_id=Administrator; Path=/; SameSite=Lax
Set-Cookie: user_image=; Path=/; SameSite=Lax
Connection: close

Headers from failing example:

HTTP/2 200 OK
content-encoding: gzip
content-type: text/plain; charset=utf-8
date: Mon, 10 Jul 2023 14:33:30 GMT
referrer-policy: same-origin, strict-origin-when-cross-origin
server: nginx/1.18.0
set-cookie: sid=3....; Expires=Thu, 13 Jul 2023 14:33:30 GMT; HttpOnly; Path=/; SameSite=Lax
set-cookie: system_user=yes; Path=/; SameSite=Lax
set-cookie: full_name=Kevin%20Horan; Path=/; SameSite=Lax
set-cookie: user_id=k...g; Path=/; SameSite=Lax
set-cookie: user_image=; Path=/; SameSite=Lax
strict-transport-security: max-age=63072000; includeSubDomains; preload
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
X-Firefox-Spdy: h2

[developmentforpeople]

Mmmm thanks for your help @khoran. I just tried into my environment with updated Frappe (14.39.0), uploaded your example .xlsx file and it works for me. Ideas of how to solve it for you and what could be interfering:

• Update to a higher Frappe version to try and compare :)
• Try within an incognito window without any extension installed, or even other browser. For example I have a browser that usually I do not use without extensions (or just other profile for some tests without extensions ;).
• If above does not work, just try debugging within VScode. I will attach some screenshots of my debugging below :) The important thing is setup a breakpoint in line 18 within file "apps/frappe/frappe/website/serve.py", or a print, and check the headers there, in server, just before being sent to browser to see if mime type is ok there.

It seems that some extension or some proxy between your environment and your browser is "updating" the headers.

Please tell me if you need more help :)

PD. The most important thing I see in the headers you sent is that ALL headers names are lowercased, except one: X-Firefox-Spdy. Maybe the problem is that. What is adding the Firefox-SPDY?
PD. And other thing is the one working is served by "Server: Werkzeug/2.2.2 Python/3.10.5" and the other by "nginx/1.18.0".

My headers in today test:

Connection: close
Content-Length: 4658
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date: Mon, 10 Jul 2023 18:49:36 GMT
Server: Werkzeug/2.2.3 Python/3.10.5
Set-Cookie: full_name=Administrator; Path=/; SameSite=Lax
Set-Cookie: sid=70398cad61c03ece1f4bc62ae1ee69cc8af00b3e0a20e38808835aa6; Expires=Thu, 13 Jul 2023 18:48:00 GMT; HttpOnly; Path=/; SameSite=Lax
Set-Cookie: system_user=yes; Path=/; SameSite=Lax
Set-Cookie: user_id=Administrator; Path=/; SameSite=Lax
Set-Cookie: user_image=; Path=/; SameSite=Lax

Some screenshost could help you to debug:

[developmentforpeople]

You are welcome @khoran, and happy to see you found it! Thank you for sharing it with me and other possible users. I had a similar issue with locales because we usually forget the OS layer! :)