PDA

View Full Version : QNAM and failed ftp requests



mcarter
19th April 2013, 16:03
So I have moved passed my QUrl (http://www.qtcentre.org/threads/54180-QUrl-QNAM-access-to-local-login-file) situation and now working on downloading files. I was going to go with QFtp but saw QNAM is the new way to go. I have started with looking at the downloadmanger example code. Working with this for less then a day, I think I have uncovered a bug in QNAM logic.

If I have the correct username/password and the host is up, then everything works as expected . . . the appropriate files get downloaded. btw, with ftp, does QNAM download the files in parallel or one at a time? Is there a limit on how many requests QNAM will queue up?

However, if there is an authenication error because of bad username/password, then the internal cache logic of QNAM goes wacky. Try this: ./downloadmanager ftp://test:case@localhost/file.dat ftp://test:case@localhost/test.dat

I get the following output:


Downloading ftp://test:case@localhost/file.dat...
QNetworkAccessCache::removeEntry: trying to remove key 'ftp-connection:ftp://localhost:21' that is not in cache
[### ] 0.0 bytes/sec
Failed: Logging in to localhost failed: authentication required
Downloading ftp://test:case@localhost/test.dat...


and then it never returns. If you try with ftp://test:case@localhost/file.dat ftp://test2:case2@localhost/test.dat, the program segfaults.

The removeEntry line seems to be a flag. Digging a bit in the code, the qnetworkaccessftpbackend.cpp is the culprit. It uses a makeCacheKey method to build a key for adding/removing entries in the cache. During the open, the key is built from initial url, which for the example above, is 'ftp-connection:ftp://test@localhost:21' (includes scheme,username,host), and calls addEntry(key) for cache. With the ftpDone slot, if there is an authetication error, it first clears out the username/password for the current url. Tries authentication, if required, but that fails. So later in that slot when it uses makeCacheKey to then call removeEntry(key) on cache, the new url produces a key of 'ftp-connection:ftp://localhost:21' without the username, which is not a match and thus the warning and the cause of the cache problem. Since the original entry is still in the cache, any other url to be processed that has the same key will be ignored since it assumes that entry is already being processed. What is th cache being used for?

This seems to be a bug in QNAM process. Qt Bug Reporting is somewhat slow, so I wanted to check here to see if anyone else had a problem and to check my logic. Not completely sure of the proper fix, unless you call makeCacheKey somewhere towards the beginning of the slot before the url is modified.

I need to support Qt 4.6, so I may have to go the QFtp route to avoid this bug.