Question about HTTP KIO Slave

[David Narvaez]

Reposting here in case someone has an idea:

Hi all,

I'm working on a fix for a bug we have in KGet, where some files are
downloaded incomplete. I found that at least one of the reasons why
this happens is because of the following use case. when KGet is set up
as the download manager for Rekonq:

1. Rekonq requests a URL, compressed pages are allowed
2. Rekonq gets the MIME type and puts the slave on hold because it is
not a supported type
3. KGet kicks in and a transfer plugin requests the same URL (no need
to know what a transfer plugin is, just know it does not support
compressed pages)
4. KLauncher decides the URL was already requested so it assigns the same slave
5. The slave reports the compessed transfer size, the transfer plugin
gets the wrong size and the file is downloaded incomplete

In that scenario, shouldn't the HTTP slave know that the new metadata
is not compatible with the previous one and restart the request? I
worked around this issue by reading response headers and
killing/restarting the KIO::get when compressed encoding was detected,
but that's of course ugly. Another trick I tried was to recognize the
old metadata was not compatible with the new metadata at the slave
level, and restart the request, but code was getting messy so I never
finished that approach.

Any ideas of what to do with this scenario? Can this be considered a
bug in HTTP KIO Slave?

David E. Narváez