I just want to share some information; it is in reference to having a Nextcloud 19 behind a reverse proxy powered by IIS and iOS gadgets being unable to connect.
The road was long enough to lose the faith. I was almost going to throw the towel, and just get on about not being able to let iOS users to connect to Nextcloud. But at last I got it working and i just want to share my experience. Maybe this post can guide someone.
The infrastructure looks more ore less like that:
Nextcloud was working flawless everywhere but iOS machines. So, I knew that NC was not being the problem.
The first contact was about a blank page on iPhone’s browsers, no error, so I was unable to get information here. Second approach was with the nextcloud APP, it gave me a bit more of information, protocol error it said. I started looking about SSL troubles on iOS. I was hitting a rock… I’m not using a selfsigned cert, it is issued by rapidssl, etc…
Accidently I got to some nextcloud pages talking about an Apache being after Nginx reverse proxy, and some troubles about the headers. Well it seems we were getting closer. BUT and it’s a big but, I am not using Nginx so it was not very helpful to me.
After some time, I bounced to this Nextcloud post. Hey look the title, its nearly as mine but instead of IIS it was another product. So, I read it carefully. It said something about changing the header configuration not on Nginx, since this guy was like me, he doesn’t have Nginx, but on the apache server. Ok I just had to add “Header unset Upgrade” into “/etc/apache2/apache2.conf”. He was very happy, moreover, there were one reply telling literaly: “YESSSSSS!!! I have been banging my head against the wall on this for WEEKS! Thanks for the solution!” By goatymoose. So maybe this is the trick. But… no, It didn’t work yet.
Could it be NC trouble? Lets try bypassing the reverse proxy, maybe I should do that in the first place but I was so confident the Nextcloud installation was ok. And I was right. I bypassed the IIS core just by doing a 443 pnat directly to the Nextcloud IP… and… it worked flawlessly, but I need my reverse proxy being in front because I have got other webapps like the OCS from the image. Ok what next?
I knew there were something more on that post, the op showed us a link to a tutorial So I started Reading this post very careful. Everything was around the upgrade header, so it was not use for me, but the tutorial talked about how he got to the error, using Curl connection to get the reply from the server. I didn’t get anything from the logs on apache nor IIS but well lets try it out.
So, after all, I was having invalid http header! But it was about “keep-alive”. So finally there is the solution.
I disabled keep alive configuration by setting it off “KeepAlive off” from apache2.conf, restarted apache service and… Viola! Its working now, yeah iOS users can connect now. Lets see curl again:
Here goes a third image
Disclaimer: Since I just created the account, I can’t post more than 2 images, basically it doesn’t throw any error now.
Hey it looks different now!
Some thoughts about it:
Why it was not working only on iOS?
- I don’t really know. But the truth is that it is working now.
Will it make the connection slowly, or lose performance?
-My first impression was yes, but it seems not because on the reverse proxy there is the keepalive too, and the connection from the reverse proxy to the backend app its really fast so it have no impact. I got the information from: https://serverfault.com/questions/426726/do-http-reverse-proxies-typically-enable-http-keep-alive-on-the-client-side-of-t
The specific quote: “ If HTTP Keep-Alive is so great, why not use it on the server side as well?
HTTP reverse proxies (like HAproxy) are typically deployed very close to the backend servers they are proxying for. In most cases the latency between the reverse proxy and its backend server/s will be under 1ms, so establishing a TCP connection is much faster than it is between a client.
That’s only half the reason though. An HTTP server allocates a certain amount of memory for each client connection. With Keep-Alive, it will keep the connection alive, and by extension it’ll keep a certain amount of memory in use on the server, until the Keep-Alive timeout is reached, which may be up to 15s, depending on server configuration.
So if we consider the effects of using Keep-Alive on the server side of an HTTP reverse proxy, we are increasing the need for memory, but because the latency between the proxy and the server is so low, we get no real benefit from the reduction in time taken for TCP’s 3-way handshake, so its typically better to just disable Keep-Alive between the proxy and the web server in this scenario.
Disclaimer: yes, this explanation doesn’t take into account the fact that browsers typically establish multiple HTTP connections to a server in parallel. However, there is a limit to how many parallel connections a browser will make to the same host, and typically this is still small enough to make keep-alive desirable.
Thanks to everyone posting your tests here in help.nextcloud.com. Thanks to you I was able to fix it.