Hi,
as Volker said, without any alternative, we can't just ban QNAM.
And even with one, we would need time to implement it (for example,
for GCompris, this part of the code was written by someone who is less
active now, so rewriting it, testing it and be sure it works will take
some time).
Can't
On Thu, Feb 20, 2020 at 9:57 PM Volker Krause wrote:
>
> On Wednesday, 19 February 2020 10:04:11 CET Ben Cooksley wrote:
> > On Wed, Feb 19, 2020 at 9:30 PM Volker Krause wrote:
> > > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > > On Mon, Feb 3, 2020 at 7:42 AM Volker
El dijous, 20 de febrer de 2020, a les 14:29:47 CET, Allen Winter va escriure:
> On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> > El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va
> > escriure:
> > > Additionally, improved documentation, a possible
El jue., 20 de feb. de 2020 a la(s) 10:30, Allen Winter
(win...@kde.org) escribió:
>
> On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> > El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va
> > escriure:
> > > Additionally, improved documentation, a
On Wednesday, February 19, 2020 6:09:02 PM EST Albert Astals Cid wrote:
> El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va
> escriure:
> > Additionally, improved documentation, a possible KNAM and/or driving the
> > QNAM
> > changes upstream can still be done alongside
On Wednesday, 19 February 2020 10:04:11 CET Ben Cooksley wrote:
> On Wed, Feb 19, 2020 at 9:30 PM Volker Krause wrote:
> > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote:
> > > > I agree on the problem of QNAM's default,
El dimecres, 19 de febrer de 2020, a les 9:28:22 CET, Volker Krause va escriure:
> Additionally, improved documentation, a possible KNAM and/or driving the QNAM
> changes upstream can still be done alongside this obviously.
Also for Qt5 which will probably never be changed a clazy warning and
El dimecres, 19 de febrer de 2020, a les 8:05:01 CET, Ben Cooksley va escriure:
> The easiest path forward is to simply ban QNetworkAccessManager.
Stop saying that, that's not going to happen.
Cheers,
Albert
>
> >
> > Regards,
> > Volker
>
> Regards,
> Ben
>
On Wed, Feb 19, 2020 at 9:30 PM Volker Krause wrote:
>
> On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote:
> > > I agree on the problem of QNAM's default, see also
> > > https://conf.kde.org/en/
> > >
On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote:
> > I agree on the problem of QNAM's default, see also
> > https://conf.kde.org/en/
> > akademy2019/public/events/135 on that subject.
> >
> > On Saturday, 1 February 2020
On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote:
>
> I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
> akademy2019/public/events/135 on that subject.
>
> On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> [...]
> > Prior to now, i've taken the approach
[...]
> 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:
On Mon, Feb 3, 2020 at 11:51 PM Johan Ouwerkerk wrote:
>
> On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote:
> >
> > Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit :
> > > I updated:
> > >
> > > https://community.kde.org/Policies/API_to_Avoid
> > >
> > > Which had no mention
On Mon, Feb 3, 2020 at 10:49 PM David Edmundson
wrote:
>
> I updated:
>
> https://community.kde.org/Policies/API_to_Avoid
>
> Which had no mention of this.
Many thanks for updating the wiki David.
>
> David
Cheers,
Ben
On Monday, 3 February 2020 10:49:10 CET David Edmundson wrote:
> I updated:
>
> https://community.kde.org/Policies/API_to_Avoid
>
> Which had no mention of this.
Thanks for taking care of this!
I'd propose a slightly different approach than the per-request all-or-nothing
attribute mentioned
On Mon, Feb 3, 2020 at 11:27 AM laurent Montel wrote:
>
> Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit :
> > I updated:
> >
> > https://community.kde.org/Policies/API_to_Avoid
> >
> > Which had no mention of this.
> >
> > David
>
> I think that you made an error
>
>
No, no. Please go the other way round and update the wiki to whatever
working code you have.
David
Le lundi 3 février 2020, 10:49:10 CET David Edmundson a écrit :
> I updated:
>
> https://community.kde.org/Policies/API_to_Avoid
>
> Which had no mention of this.
>
> David
I think that you made an error
"networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute,
true); "
I updated:
https://community.kde.org/Policies/API_to_Avoid
Which had no mention of this.
David
On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote:
>
> I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
> akademy2019/public/events/135 on that subject.
>
> On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> [...]
> > Prior to now, i've taken the approach
I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
akademy2019/public/events/135 on that subject.
On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
[...]
> Prior to now, i've taken the approach of advertising that
> QNetworkAccessManager is broken and needs a
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'
22 matches
Mail list logo
