Infrastructure

In my Debian Sid environment, I was able to download it in both Firefox(86.0) and Chromium(88.0.4324.182).

We exchanged information about it at Japanese team meeting. I've heard the following information

In Chrome, it couldn't be downloaded from the language pack link on the download page.
https://ja.libreoffice.org/download/download/?type=mac-x86_64&version=7.1.0&lang=ja
http://download.documentfoundation.org/libreoffice/stable/7.1.0/mac/x86_64/LibreOffice_7.1.0_MacOS_x86-64_langpack_ja.dmg (link)

However, Nogata-san was able to download it from the language pack link on the next page.
https://ja.libreoffice.org/donate/dl/mac-x86_64/7.1.0/ja/LibreOffice_7.1.0_MacOS_x86-64.dmg
https://download.documentfoundation.org/libreoffice/stable/7.1.0/mac/x86_64/LibreOffice_7.1.0_MacOS_x86-64_langpack_ja.dmg (link)

I thought the difference was http and https.

Shinji Enoki wrote:

I thought the difference was http and https.

I guess recent Chrome/Chromium versions refuse to download software when the chain of redirect have a cleartext link, even when the software itself is downloaded from a mirror over TLS.

The browser console likely had some details about why the download didn't proceed. Anyway I upgraded the links now, does it help?

Hmm. Cannot reproduce - the links on the main download-page also is https://download.documentfoundation.org/… for me, and while there can be problems when mirrorbrain hands out a http mirror when coming from https (that's where the download - or rather the protocol downgrade in a redirect - is blocked by the browser), only one mirror in asia region is using http, the others, especially the two in Japan are https, and the one in Indonesia is even limited to only handle request from Indonesia only:

sudo -u mirrorbrain mb list -H -r as --country --country-only
mirror.isoc.org.il             il https://mirror.isoc.org.il/pub/tdf/                     country_only=True
nju.edu.cn                     cn https://mirrors.nju.edu.cn/tdf/                         country_only=False
ftp.kaist.ac.kr                kr https://ftp.kaist.ac.kr/tdf/                            country_only=False
free.nchc.org.tw               tw https://free.nchc.org.tw/tdf/                           country_only=False
ftp.iitm.ac.in                 in https://ftp.iitm.ac.in/tdf/                             country_only=True
koddos.net                     hk https://mirror-hk.koddos.net/tdf/                       country_only=False
freedif.org                    vn https://mirror.freedif.org/TDF/                         country_only=False
kambing.ui.ac.id               id http://kambing.ui.ac.id/tdf/                            country_only=True
ftp.kddilabs.jp                jp https://ftp-srv2.kddilabs.jp/office/tdf/                country_only=False
library.ucy.ac.cy              cy https://mirror.library.ucy.ac.cy/tdf/                   country_only=False
labkom                         id https://mirror.labkom.id/tdf/                           country_only=False
datautama.net.id               id                                                         country_only=False
estointernet.in                in https://mirrors.estointernet.in/tdf/                    country_only=True
download.nus.edu.sg            sg https://download.nus.edu.sg/mirror/tdf/                 country_only=False
ftp.yz.yamagata-u.ac.jp        jp https://ftp.yz.yamagata-u.ac.jp/pub/tdf/                country_only=False

could of course be that the region detection based on the IP fails/that the assignment or IPs changed and it is not reflected int the geolocation database.

But if you can still reproduce, the web-developer console in chrome should provide some more info (ctrl+shift+c on linux, so probably command+shift+c on mac)

so a few things need to be clarified:

• do you really get a URL http://download.documentfoundation.org instead of https://download.... from the Japanese page? (https://ja.libreoffice.org/download/download)? That would be pretty strange, since while the other download links use the "use-same-method as parent page" link stype (<a href="//download.documentfoundation.org/....">text</a>), the link for the langpacks or helppacks has an explicit https: prefix (<a href="https://download...&gt;text&lt;/a&gt;)
• in case of not being able to download: is there an error listed in web developer console? (ctrl/cmd+shift+c)
• in case of not being able to download, what are the top mirrors listed when you append .mirrorlist to the download URL ( https://download.documentfoundation.org/libreoffice/stable/7.1.1/mac/x86_64/LibreOffice_7.1.1_MacOS_x86-64_langpack_ja.dmg.mirrorlist )/what does it list as detected country/region/continent?
• does it work to copy and paste the download link into the URL bar instead of clicking it on the download page? (i.e. does pasting https://download.documentfoundation.org/libreoffice/stable/7.1.1/mac/x86_64/LibreOffice_7.1.1_MacOS_x86-64_langpack_ja.dmg into the URL bar and hitting enter work in that case?)

Christian Lohmaier wrote:

Hmm. Cannot reproduce - the links on the main download-page also is https://download.documentfoundation.org/…

I changed that yesterday, it was http:// before.

Thank you for the fix and comments!

We checked it at today's Japanese Team meeting.
It was not reproduced in Chrome in the environment of all four meeting participants including Nogata-san.

I don't know the reason. There is a possibility of the effect of the Gillem's fix or the version upgrade of Chrome, or http mirror server has not been hit.

This doesn't seem to reproduce now,
so I think it's okay to close.