Bug #9770
closedLinux version download link not working
Added by Jordi Guri almost 3 years ago. Updated almost 3 years ago.
0%
Description
The linux download link at:
https://trac.chirp.danplanet.com/chirp_daily/LATEST/chirp-daily-20220219.flatpak
does not download the file. Instead this link browses the file. All other chirp download links (eg. Windows) seem to be working fine).
Updated by Jim Unroe almost 3 years ago
- Status changed from New to Feedback
It worked perfectly fine for me. I now have 3 copies of chirp-daily-20220219.flatpak, 1) downloaded on the day the build was created, 2) just now downloaded form the link on the CHIRP download page and 3) using the link that you provided above.
Jim KC9HI
Updated by Jordi Guri almost 3 years ago
Thanks Jim,
I'm using Brave browser which is based on Chromium. Both Brave and Chromium browsers cannot download that particular file/link ending in .flatpak. They both just open up the file as though it is a text file so that you can see its contents. With all of the other download links (Windows, Mac/Os, .exe, .tar) these 2 browsers work fine and these other files download just fine.
I then downloaded and installed Firefox, and this downloads the .flatpak file just fine, so I now have the latest flatpak. For your info ...
If I were to hazard a guess, this seems like a "mime filetype" setting problem with the http server? Not sure though.
Updated by Jim Unroe almost 3 years ago
Jordi Guri wrote:
Thanks Jim,
I'm using Brave browser which is based on Chromium. Both Brave and Chromium browsers cannot download that particular file/link ending in .flatpak. They both just open up the file as though it is a text file so that you can see its contents. With all of the other download links (Windows, Mac/Os, .exe, .tar) these 2 browsers work fine and these other files download just fine.
I then downloaded and installed Firefox, and this downloads the .flatpak file just fine, so I now have the latest flatpak. For your info ...
If I were to hazard a guess, this seems like a "mime filetype" setting problem with the http server? Not sure though.
I loaded my Google Chrome browser to experience what you are seeing. That a browser behavioral issue, not a CHIRP website problem. Probably because Chrome has the "flatpak" extension associated with something else and the CHIRP flatpak is not meant for that "something else". What you need to do is right-click the link and choose "Save link as...". It worked for me.
Jim KC9HI
Updated by Jordi Guri almost 3 years ago
Thanks for your help, Jim. You can close this one off.
Jordi
Updated by Jim Unroe almost 3 years ago
- Status changed from Feedback to Resolved
Jordi Guri wrote:
Thanks for your help, Jim. You can close this one off.
Jordi
Thanks for the follow up.
Jim
Updated by Jordi Guri almost 3 years ago
Hi again, Jim.
Oops, sorry not quite closed yet! :)
From your last response:¶
That a browser behavioral issue, not a CHIRP website problem.
After extensive reading up on Mime types, Content-Type, http servers & browsers, this bug is not a browser problem.
The Mime "Content-Type" for each file (like the Chirp Download files) should be set in the server and not left up to the browser to determine (or change) what the server had intended. Otherwise each browser will have to guess at (or override) what the server's intentions are. For Chirp downloads, in the case of the Chrome browser this assumes that ".flatpak" is a text file, while the Firefox browser assumes that a ".flatpak" is to be downloaded.
If you right-click in any browser and select "inspect", and in the "inspect" frame, select "Network", you can then see what the http server's response is for each file request, by selecting each file element on the downloads page.
This is what I am seeing on the https://trac.chirp.danplanet.com/chirp_daily/LATEST/ page for the downloadable files:
filetype: .flatpak¶
Accept-Ranges: bytes
Content-Length: 19262872 <--- Content-Type is NOT specified by the server
Date: Fri, 04 Mar 2022 20:16:58 GMT
ETag: "220aad-125ed98-5d85a71d34a43"
Last-Modified: Sat, 19 Feb 2022 08:04:11 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
filetype: .gzip¶
Accept-Ranges: bytes
Content-Length: 1037302
Content-Type: application/x-gzip <--- Content-Type is specified by the server
Date: Fri, 04 Mar 2022 20:52:16 GMT
ETag: "220aac-fd3f6-5d85a719343d1"
Last-Modified: Sat, 19 Feb 2022 08:04:07 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
filetype: .exe¶
Accept-Ranges: bytes
Content-Length: 11304216
Content-Type: application/x-msdos-program <--- Content type is specified by the server
Date: Fri, 04 Mar 2022 20:56:25 GMT
ETag: "220aaa-ac7d18-5d85a7161f2f5"
Last-Modified: Sat, 19 Feb 2022 08:04:04 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
In summary, there is no Mime "Content-Type" specified for ".flatpak" files in the Apache server for chirp.danplanet.com. Thus, different browsers will make different assumptions for these files coming from Chirp's Apache server. For filetype ".flatpak" the "Content_Type" needs to be set in the Chirp Apache server (.htaccess file?).
I found further reading on this at:
https://developer.mozilla.org/en-US/docs/Learn/Server-side/Configuring_server_MIME_types
For your info ...
Jordi