Banning QNetworkAccessManager

[Ben Cooksley]

Hi all,

For an extremely long time now, it has been a known issue with the
QNetworkAccessManager that by default it does not follow redirects as
issued by the server it is accessing. This is something the Qt Project
has refused to address using the justification of 'behavioural
compatibility'

This behaviour is contrary to that of just about every other HTTP
stack (with the exception of libcurl from my understanding) and is
behaviour that nobody expects.

As a consequence of this (broken) behaviour, Sysadmin has been
effectively forced to implement workarounds and other compatibility
measures in place to keep applications functional. These measures harm
the long term maintainability of our systems, and sometimes limit our
ability to make services more scalable. In some instances, the cost of
compatibility measures would be too high, resulting in functionality
of applications being broken. I am aware of at least one instance
where if a compatibility measure we maintain is removed, the
application will crash (segfault) during it's operation (a failure
that makes the application unusable)

Prior to now, i've taken the approach of advertising that
QNetworkAccessManager is broken and needs a flag set within
applications when used, however unfortunately this seems to have been
an ineffective approach and cases of broken behaviour continue to
appear (despite this brokeness being known about and advertised since
back in the Qt 4.x series when this class was introduced)

Therefore, given the Qt Project is unlikely to change their position
on this, I would like to propose the following:
1) That effective immediately, QNetworkAccessManager and it's children
classes be banned and prohibited within KDE software, to be enforced
by server side hooks.
2) That we fork QNetworkAccessManager and the associated classes
within the appropriate Framework (to be determined), where the
defective behaviour can then be corrected.

Comments?

Regards,
Ben Cooksley
KDE Sysadmin