URL::readEntireTextStream(true) not working... on some computers?

Hi folks. I have a rather bizarre issue, and I’m not sure if it’s a Juce issue or not, but it’s very difficult to decipher so perhaps one of you smart folks will have an idea :).

In my Windows/macOS app, a POST command is issued to retrieve a user’s information from my server, more or less like this: myServerURL.readEntireTextStream(true). This has been working for years without any problems. But in the last month or two, a couple of my customers have let me know they are getting an error message that my server can’t be contacted, which (from a code standpoint) means that the readEntireTextStream command is returning an empty string. When I look at my server’s SSL log, there isn’t even a record of an attempted connection from the user’s IP address. Now, keep in mind, this is only happening for some users. And, it doesn’t seem to be specific to Windows or Mac. I can’t duplicate the problem on any of my computers.

The very strange thing is that the error only happens when coming from the Juce code in my app. If a user (who is getting the error) goes to my server through a browser, there is no problem.

Is there something different from how Juce retrieves text from a URL vs how a browser does it? Also, why is this only happening in the last month or two? There have been absolutely no relevant code changes.

I wonder if it’s some new security feature in the OS’s, or something like that, which is blocking POST requests from within executables?

Any thoughts/ideas appreciated, and please feel free to ask any questions to clarify.

Thanks so much!

Well… very hard to debug anything like this unless you can actually reproduce it. If there was some code you could run that fails then you can dig into it and see exactly which OS functions are failing, and then guess about why. But I don’t really know what we could do otherwise, I’m afraid…

Thanks Jules. In case it helps anyone else, I think I figured out the problem. Apparently, June 30 2018 was the deadline for many web servers to stop supporting TLS 1.0 (primarily for PCI compliance). My web hosting provider did this without my knowledge.

My Windows/OS X software was communicating with my web server through an https URL, and readEntireTextStream was therefore failing on any operating system that did not support TLS 1.1/1.2. Apparently, this mostly affects OS X, because OS X versions before El Capitan (10.11) do not have support for TLS 1.1/1.2.

It was also affecting Windows 7, but there is an easy way to fix it, as described here: https://www.computerworld.com/article/3208077/internet/tweaking-internet-explorer-to-only-use-tls-1-2.html. This looks like it is only for Internet Explorer, but it actually affects all Windows networking functionality.

Also in case it helps anyone else, there is a difference between browser support for TLS 1.1/1.2, and OS support for it. Safari on OS X Mavericks works, but OS X Mavericks itself doesn’t (when using readEntireTextStream).

So, if you’re wondering why your https-related Juce code isn’t working on older OS’s, now you have the answer. It’s not Juce’s fault, it’s just the networking libraries on those OS’s.


Thank you for reporting back. That’s some really useful info!

Wow, what a pain. At least there is no App Transport Security in Mavericks else there might not even be the possibility to fall back to http!