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