HTMLViewer Error -1022

My app communicates important info to a server using HTMLViewer. It has done this for years with no problem.

Older versions of my app are now seeing an error number -1022 instead of expected content. This is leaving a ton of older apps stranded with no way to connect.

My server IS secure using https - connecting via browser shows a good certificate.

The older app versions are using an “http” url, but my server redirects “http” requests to “https” and this has worked fine - both for ShowURL browser requests as well as with HTMLViewer.

Why is HTMLViewer in older app now throwing an error even though the server redirects to a secure url?

Is there some magic .htaccess code that can prevent this error?

Very frustrated here.

Following up with more info, the current Language Reference for HTMLViewer.LoadURL states:

On macOS, you need to ensure the URL is prefixed with "http://" or "https://" in order for it to load.

And example code from same:

Var url As String = URLField.Value If Left(url, 7) <> "http://" Then url = "http://" + url HtmlViewer1.LoadURL(url)

you need to add a info.plist file to your project, to bypass network security in recent systems.
see here : https://documentation.xojo.com/topics/communication/internet/using_non-secure_urls_on_macos_and_ios.html

[quote=482865:@Jean-Yves Pochez]you need to add a info.plist file to your project, to bypass network security in recent systems.
see here : https://documentation.xojo.com/topics/communication/internet/using_non-secure_urls_on_macos_and_ios.html[/quote]

OK thanks, but that article states:

Thing is, I DO have control over the connection, and it IS secure. I’m not wishing to connect to a non-secure site.
It’s just that my older app versions call an “http” url. Is Xojo HTMLViewer just relying on the url and rejecting it before it even attempts to connect? If so that is a huge error that breaks a lot of older apps.

I hope this is not the case and there is some server-side patch that I can use to allow HTMLViewer to accept the redirect to the secure url. I already employ an .htaccess file that works fine on ShowURL and httpSecureSocket:

RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

It’s not an error, it’s an intentional move by Apple. They say it’s for user security. This only affects users running your old app on newer operating systems. There is nothing you can do for existing builds.

even if it is https, you still need this info.plist file. starting macos 10.11 or something.
or you get this error 1022. you choose !

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
<key>NSAppTransportSecurity</key>
  <dict>
  <key>NSAllowsArbitraryLoads</key>
  <true/>
  </dict>
  </dict>
</plist>

[quote=482863:@Richard Nicolella]Following up with more info, the current Language Reference for HTMLViewer.LoadURL states:

On macOS, you need to ensure the URL is prefixed with "http://" or "https://" in order for it to load.

And example code from same:

Var url As String = URLField.Value If Left(url, 7) <> "http://" Then url = "http://" + url HtmlViewer1.LoadURL(url)
[/quote]
Sorry to say that the docs are wrong. I think from Xojo2018r4 and up you must always use https:// if you use http:// you will not get the page. Older Xojo (like 2018r2) will show the page.

Simple test:

If you use Xojo2018r2 both viewers will show the page. If you use Xojo2019r1.1 or r3.1 only the one with https will work.

I think its wrong to say this is a Apple thing. If it was Safari would act this way - it does not. Neither does Xojo’s own httpSecureSocket. Both of those dutifully process the “http” request and allow themselves to be graceful upgraded to a secure connection.

I think this is a Xojo bug in HTMLViewer. It is discarding the http request on-sight, instead of trying to achieve a secure connection with it.

A real headache for me, as hundreds of my installations are unnecessarily stranded without communication.

-1022 is
CFNetworkErrors.h kCFURLErrorAppTransportSecurityRequiresSecureConnection -1022
NSURLError.h NSURLErrorAppTransportSecurityRequiresSecureConnection -1022

The OS is blocking an insecure URL (http)
You dont seem to have many options other than to update your app and insert the plist entry Jean-Yves suggests
And then get these people to download an updated version

Been there, done that, got the t-shirt: “Dear customers, due to the GPDR the updater got broken. Please update manually.” The update checker should have upgraded from http to https. It didn’t.

Its tough but when the OS forces it down your throat …

[quote=482873:@Richard Nicolella]
Thing is, I DO have control over the connection, and it IS secure.
(…)

RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}[/quote]

Sorry, but this is either secure nor a solution. The security in your example is based on the server side. Every proxy or any redirected query could circumnavigate this and make your communication readable. You have to use TLS initially and the answering request must be checked, if the servers’ cert is valid and matching.

And when talking about updater functions. This is a well known scenario. Anybody remembers how the malware Not-Petya emerged couple of years ago? It was introduced as an update for an official tax office app. The updater failed to check the server and its certs (and the checksums of the downloaded update aswell) and so it loaded and started the malware.

As a golden rule of thumb: Take extra precautions when trying to load something from others’ computers.
These restrictions are good and really needed.