upgrade check failure

[tsteven4]

Ubuntu finally released the fix to Qt6 QLibraryInfo for jammy. But we have a couple of new issues:

1. If we download from Qt then the expected OpenSSL versions aren't compatible. jammy has 3.0.2, Qt expects 1.

We get the popup

and the console shows:

qt.tlsbackend.ossl: Incompatible version of OpenSSL (built with OpenSSL 1.x, runtime version is >= 3.x)
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslKey
qt.network.ssl: Active TLS backend does not support key creation
qt.network.ssl: The backend "cert-only" does not support QSslSocket
qt.network.ssl: The backend named "cert-only" does not support TLS
qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed

2. If we use the ubuntu supplied Qt6, then (testing true, qDebug() << oresponse)
   (also notice two periods in the popup)

Warning: Ignoring WAYLAND_DISPLAY on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
http status code  200
"NULL\nNULL\n0"

Now, if we change the upgrade check method from http to https then the testing message notifying the user an upgrade from 1.3.1 is presented as expected.

[tsteven4]

This was with 7b321cd, the current HEAD->master.

[tsteven4]

and Qt 6.2.4

[tsteven4]

Also see https://www.qt.io/blog/moving-to-openssl-3-in-binary-builds-starting-from-qt-6.5-beta-2

[tsteven4]

The issue with the popup "Invalid return data at line 1: Start tag expected.." also occurs on macOS. It appears that gpsbabel.org doesn't respond well to redirects which are reissued using GET. upgrade issues a POST using the http scheme.

Note: When Qt handles redirects it will, for legacy and compatibility reasons, issue the redirected request using GET when the server returns a 301 or 302 response, regardless of the original method used, unless it was HEAD.

@robertlipe can you please look at this?

[robertlipe]

Oh, gross. I thought we moved that to https years ago. I've been trying to force upgrade our connections to https on the server because Google is penalizing us for duplicate content for serving both http://foo and https://foo, so there has been a recent change here. uc.html itself hasn't changed in over a year so this is a .htaccess thing for me, though it's odd you're not seeing even the XML header. There may also be a change in our hosting that's coming into play here. Rats! I'll investigate. Sorry to introduce another variable into your work. RJL P.S. I plan to turn down some of the old htmldoc-X versions, probably leaving only 1.7 and htmldoc-development. We're currently serving back to 1.4.3 and there are problems in those pages penalizing our site performance that I don't feel like hand-fixing in ancient versions.

…

On Mon, Jan 9, 2023 at 7:39 AM tsteven4 ***@***.***> wrote: Assigned #972 <#972> to @robertlipe <https://github.com/robertlipe>. — Reply to this email directly, view it on GitHub <#972 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32XOLQ4OWCHKQ47TKLWRQIH3ANCNFSM6AAAAAATRCUJD4> . You are receiving this because you were assigned.Message ID: ***@***.***>

[tsteven4]

The invalid return data popup has been reported again on gpsbabel-misc

[tsteven4]

The invalid return data popup is reproducible with 043fe4f on
ProductName: macOS
ProductVersion: 12.6.4

[GPSBabelDeveloper]

Argh. Another silent server-side change. "Thanks, Dreamhost/$LANGUAGE". I've modified it to allow the upgrade query to present upgrades. Stats collection will resume in the next couple of days. curl https://www.gpsbabel.org/upgrade_check.html should again return joy. Windows 7 and 8 and other "we have no upgrade for you" cases should work as expected. Sorry this is so messy. Dreamhost rolls the upgrade check out, verifies that our home page renders, and considers it done. upgrade_check is a very different beast internally. Maybe I have to start running a nightly crafted check to do.a form of automated CI on the server-side. But for now, the user-visible parts should again work. RJL

…

On Tue, Jun 20, 2023 at 10:27 AM tsteven4 ***@***.***> wrote: The invalid return data popup is reproducible with 043fe4f <043fe4f> on ProductName: macOS ProductVersion: 12.6.4 — Reply to this email directly, view it on GitHub <#972 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3VADZQQFSYLN4HYGADPODXMG6OVANCNFSM6AAAAAATRCUJD4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[robertlipe]

This is part of what tripped us up on the 1.9.0 rollout. I think it's because we're issuing a 301 redirect which (stupidly) converts the POST to a GET.

Looks like we may need to dole out 308's and hope that all the old clients can handle this.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308
https://stackoverflow.com/questions/42136829/whats-the-difference-between-http-301-and-308-status-codes

So running from this problem probably broke update check for a substantial number of people and I've left this in the oven for too long. :-(