Fixing QNetworkAccessManager use

[Friedrich W. H. Kossebau]

Am Mittwoch, 19. Februar 2020, 08:05:01 CET schrieb Ben Cooksley:
> On Mon, Feb 3, 2020 at 7:42 AM Volker Krause <vkrause at kde.org> wrote:
> > It would also help to know where specifically we have that problem, so we
> > can actually solve it, and so we can figure out why we failed to fix this
> > there earlier.
> 
> Just bringing this up again - it seems we've not had much movement on
> this aside from the Wiki page.

The wiki page currently still just recommends to set
"networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute, 
true);"

Which seems simple, but possible not what is enough in all cases.

So my open questions here to be able to act on code I contribute to are:

a) What about the mentioned QNetworkRequest::NoLessSafeRedirectPolicy, in 
which cases should that be used and when not?

b) What about the HSTS stuff, when is that recommended?

c) What is a sane number for QNetworkRequest::maximumRedirectsAllowed?

Both in general and when it comes to KDE servers.

Personally I am still unsure what the actual issue is. Why are redirects 
needed at all. Why all the address changes all the time? The "U" in 
"URL"/"URI" is for "uniform", not "unstable", isn't it ;)

Can you give some examples for URLs of resources our code uses on KDE servers, 
and why they needed to change?

And if those redirects are permanent, should the client side not also 
permanently update to the new location then, instead of continuing to poke the 
old address every time again and again, until one day it will poke into a void 
because the backward compat redirect support has been dropped?

Cheers
Friedrich