Syncthing seems to be experiencing a problem processing your request. Please refresh the page or restart Syncthing if the problem persists

I am running Syncthing for the first time on a Windows 7 Pro 64bit. I am only using the base product, that is, no SynTrayzor or similar, since two days. Started out with v0.14.19 and yesterday I upgraded to v0.14.20. All works well but whenever I enable the “Use HTTPS for GUI” option I start getting the message “Syncthing seems to be experiencing a problem processing your request. Please refresh the page or restart Syncthing if the problem persists” popping up once in a while. Usually it will take between 5 to 10 minutes for it to appear. This happens with both Firefox 50.1.0 and Chrome v55.0.2883.87. I’ve even tried disabling all addons and starting the browser in safe-mode but to no avail. I dived in #syncthing IRC channel and user @canton7 (as well as other cool folks) tried to help me. He told me to try and use the web developer tools that come with my browsers, open the Network tab and look for red entries in there. He also told me that that message is caused by the browser polling Syncthing, and Syncthing returning an error and that we needed to know what error this is in order to solve it. BTW, the GUI works perfectly well in between these error messages. It just stops working when these messages appear and I just need to press F5 and it goes back up working again until the next error message. I’m saying it’s an error message while it seems to be more of a warning message but I guess you get the point. :wink: Oh and the CMD window where the Syncthing is running shows no sign of problem/error. It’s just a GUI issue because Syncthing process seems to be working just fine, sync’ing files and folders in the background. So, the Network tab of the web developer tools just shows a single error and the “request” simply states that it is “”. Here’s a couple of printscreens of the error. I am using because that’s what I had to use in IRC and I still don’t quite understand these new Forum engines/skins and don’t know how to paste a picture. Here’s a paste of what I could copy from the web developer tools window on the Headers: I even went on and completely disabled the Antivirus on my computer (Sophos) and gave it a go but it happened again. This is a bit problematic because I wouldn’t want to leave the web UI available on plain HTTP/port 80 because I’m afraid I could get hacked. Not that I will be much comfortable even using HTTPS/443: this is a Windows computer after all, right?.. But anyways, it would be nice to play it by the book and have the UI available only on HTTPS. All help will be greatly appreciated. :slight_smile: Cheers

Hmmmmm… Guess I didn’t search enough or google simply didn’t catch it for me. Just decided to take a look at the Github, ran a search and look at who I found…

Same issue, right? Cheers

As long as you don’t change the listening address for the GUI, there won’t be a problem. By default, you can only connect to the gui from your computer locally.

I did some googling for SSL_ERROR_RX_RECORD_TOO_LONG, but could only find bad apache configs as a cause.

1 Like

I need to take a course to learn this forum engine/skin. :facepalm: I just wanted to quote you but I simply can’t find the right icon. It’s like when I am looking at a MS Office ribbon bar… Well, thanks a bunch for your comment. I take it that you know these things for granted but I really would feel a whole lot more relaxed if I could go HTTPS on the web UI. Otherwise you guys wouldn’t have added the HTTPS to the features, right. :wink: But thanks for the tip. Cheers

To quote, highlight the text and a box pops up.

Unless you are accessing the GUI from a different computer than sync thing is running on you don’t need https. It will add overhead to encrypt and decrypt information that is never transmitted anywhere.

What did I say. Exactly like a ribbon bar. It’s in your face but you can’t see it…:facepalm: Thanks for the tip and thanks for developing Syncthing and sharing it with us. :wink:

Does that mean that using it that way is completely safe? No one can hack the web server using Syncthing on HTTP with the default 8384 port? But that would only be a temporary workaround. I am going to install Syncthing on a small ARM computer running Arch Linux ARM which doesn’t have a VGA/DVI/HDMI port. It is completely headless. I will be forced to go HTTPS on it so that I can control it… I am going to sync all my home devices (laptops, tablets, phones) to that single device using Syncthing and then I will use it to upload to Amazon Cloud Drive using acd_cli. So, further down the road (weeks/months), HTTPS support will definitely be a must for me. TIA Cheers

If that ARM computer is behind your router, the Syncthing web interface is still not accessible to the internet (unless you want that) so unless you suspect someone / something in your local network to intercept the traffic, you still don’t need https.

No but using https does nothing in this scenario anyway. All https does is encrypt the data before sending it down the wire.

To make a long story short, unless you don’t trust the connection you use to do the administration, there’s little need to use https. It’s mainly needed if you expose the interface to the internet and set a password. If you didn’t change the listener address, the interface won’t even be accessible from other computers in your WiFi /LAN.

I also have a small headless arm server at a remote location. I do ssh tunnelling to access the gui. Exposing the Web interface would just be another possible security leak, so I don’t see a reason to do so.

Hi guys. Thanks for all your input on the subject. It’s really helpful because now I feel a whole more confident on using HTTP as a means to connect to Syncthing service and as a means of configuring it. In the end, I am quite sure that I will keep on using HTTPS to access the service because I can just refresh the window every now and then and because I will only open it when I’m about to change something in the configuration or when I just want to check something in it’s configuration. But as much as I am OK in doing this, there’s still something in my mind telling me that we are just talking about workarounds and we’re not looking at the real problem. Of course, if no one else (but me and user @grinapo) is complaining about it, I guess this is most probably down to some specifics in my base hardware/software setup. But I would really love to understand what it is because maybe it is easily avoidable. So, if anyone has any idea on how to debug this issue and is willing to help me, please go ahead and I will much appreciate it. Cheers

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.