Dr Konqi still misbehaving - advice needed

[Ian Wadham]

Hi Ben,

On 27/11/2014, at 8:05 AM, Ben Cooksley wrote:
> On Wed, Nov 26, 2014 at 8:40 PM, Ian Wadham <iandw.au at gmail.com> wrote:
>> On 26/11/2014, at 12:49 PM, Ian Wadham wrote:
>>> So far the log shows that my patch is definitely there, in the distribution, but
>>> Bugzilla still returns a 410 error, even though it has been given a token (as
>>> required for version 4.4.6 of Bugzilla software).
>> 
>> I have a feeling that KDE software behind Dr Konqi, on Linux, is still sending
>> cookies to bugs.kde.org via kio_http and maybe that confilcts with the later
>> sending of the token in the XML message-data.  See attached log extract.
>> 
>> I would not have a clue how to tackle that potential issue.  It does not happen
>> (for me) on Apple OS X, because KCookieJar is not working for me and
>> anyway my cookies are kept by Apple OS X in Safari or Firefox.
> 
> Could the user who encountered this problem logout of Bugzilla in
> Konqueror, then try to reproduce the issue perhaps?

1. I could do that, but I think it would be quicker and more efficient if someone
    from the list here could set up a test on bugstest.kde.org and reproduce the
    problem in Linux, as you originally suggested.  The bug would probably be
    reproducible in KF5, with Hrvoje's patch, if developers are really allergic to
    KDE 4… :-)  Note that to change database names, you have to edit Dr K source
    and re-compile, so then we could easily insert further logs and patches as
    the investigation progresses.  In my experience, getting users to do that kind
    of stuff is unreliable and time consuming, and anyway we surely do not want
    false or redundant crash reports going into the live Bugzilla database.

2. Should I attach the compressed log, which I sent you, to an email on this list?
    It is 11-12 Kb of bzip2.  There are lots of other strange messages in it, besides
    the ones about cookies, also some warnings I cannot interprete.

> I took a look at the Bugzilla codebase and can't see anything
> immediately wrong which would cause a proper call to be blocked simply
> because cookies were present.

Bang goes that hypothesis(?), I think this is going to be a hard one to crack...

Cheers, Ian W.