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 >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
