URLConnection error 1200 ?

“an ssl error happened and it’s impossible to make a secure connection with the server”

where does this error comes from, and how do I workaround it ?

just trying to get a file using it’s url. pasting this url in a web broswer gives me the file.


Getting a file using it’s url is surprisingly not easy. How does your code look like? Which socket to you use? Platform? You may need to adjust the SSL type for your socket.

You could try setting AllowCertificateValidation to false & see if that works. If it does that would point the issue at the provider.

same problem

you can’t adjust the ssl type with urlconnection ? only with old http sockets ?

I have a similar file that couldn’t be downloaded: https://valentina-db.com/components/com_easydiscuss/themes/wireframe/images/emails/logo.png

I had to add some special file for validating the certificate. But I’m using Curl because the newer socket had non-reproducible crashes.

[quote=445279:@Jean-Yves Pochez]“an ssl error happened and it’s impossible to make a secure connection with the server”

where does this error comes from, and how do I workaround it ?

just trying to get a file using it’s url. pasting this url in a web broswer gives me the file.

The error is from the OS as URLConnection uses native sockets (as opposed to the older sockets that were written entirely in Xojo code).

My immediate thought is that since a browser works, the server probably requires a user-agent header.

Otherwise, you might try the url as http instead. I don’t think I’ve ever seen a server downgrade a connection like that, but it’s probably not impossible.

I already tried with http instead of https, it does not work
I will try to set a user agent.

sorry, it does not work with a user agent as a requestHeader.
I also have an error of “malformed url” if there is any space in the url, even if I replace them with %20
(and of course the same url pasted in a web browser gives the file with %20 or with a space…)

I try to get the urls:
https://www.caf.fr/sites/default/files/styles/image_slider/public/cnaf/Vies%20de%20famille/RUB - Elever ses enfants/Accs aux loisirs/Partir_enlivre_2019_3.jpg

The error is coming from the system, so you should keep digging. Google suggests it’s a certificate error

this could be related to the special plist arguments you have to provide to the app, as seen in https://documentation.xojo.com/topics/communication/internet/using_non-secure_urls_on_macos_and_ios.html

is there an example of such plist file ? can I simply make it and drop it into a root xojo project ?

I make a info.plist file with the app security keys, but xojo stores it in the ressources folder, and don’t mix it with the app info.plist …
what is the way to go ?

can you use a modified info.plist on a debug app, or is it only on the compiled app ?

This appears to be a Mac thing. I’m not having a problem on Windows.

You are correct, Wayne. The newer sockets (Xojo.Net.HTTPSocket and URLConnection) use system level APIs, so the error codes are now specific to the platform.

Oh no. One of the main reasons I like Xojo is how it abstracts target differences.

The URLConnection.Error event only fires when the connection just couldn’t be made at all. The description that we had in the docs was wrong so I have just updated it. I suspect in most cases that’s all that really matters.

However, we could be mapping the most common errors to our own special set of URLConnection errors. Perhaps an enum?

So I have created a case in Feedback for this. Please feel free to sign on to it, add your own thoughts, etc.

While I can’t make any promises about when we will do this, given that URLConnection is relatively new and is part of API 2.0, I can say that I’d like to see this get done sooner rather than later.

It also means there can be be more OS specific quirks as well as X-platform performance differences… which could mean we would need to code differently by platform to get the best performance, more so than now…

Not sure using system APIs is always the best thing for a product like Xojo outside of UI stuff… I think these types of things fall into another category. I guess that understandably they are looking to be able to maintain/update less code.

Time will tell how well that works out overall for Xplatform work on our end.

  • karen

The upside to using platform native API’s is thet you then get whatever improvements fixes etc the platform makes

And you dont have to try & work around some platform silliness like https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/CommonPitfalls/CommonPitfalls.html

Plus you get native handling of things like proxies etc exactly as the OS vendor intended

That’s cool as long as we don’t need separate error testing per target.

Imagine not having SpecialFolder where you have to use a Case statement to test which target you are on to simply specify a path…