Fixing QNetworkAccessManager use

[Ben Cooksley]

On Thu, Feb 20, 2020 at 9:58 AM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> Am Mittwoch, 19. Februar 2020, 21:01:20 CET schrieb Johan Ouwerkerk:
> > On Wed, Feb 19, 2020 at 2:09 PM Friedrich W. H. Kossebau
> >
> > <kossebau at kde.org> wrote:
> > > Personally I am still unsure what the actual issue is. Why are redirects
> > > needed at all. Why all the address changes all the time?
> >
> > It is part of the HTTP spec for servers to be able to inform clients
> > that resource /foo/bar has moved to /bar/baz, either temporarily or
> > permanently.
>
> :) Thanks for that explanation, but that was not my question here (that part I
> am well aware of, done my share of web stuff).
>
> It was rather: why are subdomain names and/or access paths not once properly
> designed, but instead changed so often that redirection seems so important to
> be a default feature? Just because one can?

Things don't change extremely often.
Sometimes however requirements or other factors change, which
necessitates changing where a resource is hosted.

When this happens, it is extremely useful to have the ability to
relocate it elsewhere.

To use an example, when we first setup files.kde.org it was used by a
couple of things, including Necessitas for the Qt binaries that get
downloaded on to end user (Android) devices. When this was first
established, traffic was well within the reasonable bounds we had
expected when setting this up, and everything was served directly by
our (single) server. This went quite well for a while.

Sometime a bit later, an application was released on Google Play that
used Necessitas which was *extremely* popular, to the extent it caused
around a terabyte of data to be used within 48 hours or so. Hetzner
bandwidth was at this time not only limited to 100mbps, but also
capped - with the limit being 5 TB per month and overage after that
resulting in a charge per terabyte.

We therefore made the decision to convert files.kde.org to a mirror
network (like was already in place for download.kde.org), with
redirection taking place using Mirrorbrain. We were able to complete
this transition quickly thanks to the generous support of some of our
mirrors who established mirrors of files.kde.org. Fortunately
Necessitas had full support for handling redirects, so this is
something we were able to accomplish without any issues.

Had redirect support not been available, we would have been left with
no way out at that time.

I also have other examples involving Marble (including where we got
bitten by QNetworkAccessManager for the very first time - back in
January 2012) and numerous other KDE Edu applications (all of which
fortunately avoided QNAM).

> When we write code, we try to keep API stable as much as possible, and only
> change API when really useful, and that means for the consumer. When doing
> references in text we try to have eternally stable pointers (thanks ISBN &
> Co.),
>
> But this request for stable URLs on the internet might be an idealistic fight
> against windmills of a web 1.0 person...
>
> Cheers
> Friedrich
>
>

Cheers,
Ben