Banning QNetworkAccessManager
Johnny Jazeix
jazeix at gmail.com
Mon Feb 3 10:29:21 GMT 2020
[...]
> All of the places where we have actively hit this issue have already
> been fixed (Marble and Attica come immediately to mind, not sure if
> GCompris fixed their code).
>
I took a quick look and we use some code to handle redirection:
https://github.com/gcompris/GCompris-qt/blob/master/src/core/DownloadManager.cpp#L502
It's not the same code as mentioned by David in
https://community.kde.org/Policies/API_to_Avoid#QNetworkAccessManager,
I'll update the code tonight.
Johnny
> The rest continue to be sleeping timebombs which we will only discover
> when we change something on the server side and put in place a
> redirect. They may never be triggered, or they could be triggered next
> week. Even if we fix the code now, due to LTS distributions and people
> using software for far longer than they should, it will take years for
> the fixes to fully reach user systems.
>
> To illustrate how long this takes, Marble moved from using
> http://files.kde.org/marble/maps/ to https://maps.kde.org/ back in
> January 2016. Four years later, we still get 13,000 hits to paths
> under the old URL every day. The version numbers sent by Marble as
> part of these requests indicate that some of them are from the version
> released with KDE 4.14 which was released back in August 2014
> (fortunately this code path was fixed to follow redirects prior to
> that release)
>
> >
> > Regards,
> > Volker
>
> Cheers,
> Ben
More information about the kde-core-devel
mailing list