I tried to connect manually to the domain using openssl s_client -connect and found that it does not react to the HTTP payload. That is also the case with piwik.org hosted in the same place.

Every other host I tried reacted in a different but expected way.

The odd thing is that using a PHP socket like the unit test does fails reproducible with redirects but a connection with curl from the command line works just fine. When receiving data there is a header I have not seen anywhere else:

Via: 1.1 alproxy

Could it perhaps be a hoster issue?

> openssl s_client -connect divezone.net:443
CONNECTED(00000003)
...
SNIP CONNECTION INFORMATION
...
---
GET / HTTP/1.0


^C 

> openssl s_client -connect google.com:443
CONNECTED(00000003)
...
SNIP CONNECTION INFORMATION
...
---
GET / HTTP/1.0

HTTP/1.0 302 Found

Additional fact:

openssl s_client -connect alwaysdata.com:443 (the hoster) works properly but does not send the alproxy-header. The domain blog.alwaysdata.com sends the header and does not communicate with openssl...

https://blog.alwaysdata.com/2016/10/27/introducing-our-new-reverse-proxy-alproxy-5/

@mneudert thanks for investigating. I will for now change the host to google.com.
@mattab If you would like to change that back to divezone.net, feel free to do so, as soon as it returns "expected" headers.

We need to troubleshoot the socket connection over SSL issue at some point to check whether there is a bug in the code? the test should ideally use Piwik.org as we most often connect to Piwik.org to download content and if this breaks, it could break the auto updater or Marketplace features. Moving to 3.2.0

Created https://github.com/piwik/piwik/pull/12074/files

Fixed by @mneudert in #12074