Hi, I tried connecting with rekonq via tor (using polipo proxy) to my webserver and I noticed "GET /favicon.ico HTTP/1.1" "Mozilla/5.0" with real IP avoiding my proxy settings. Really bad for people who needs to use Tor. User agent is also reported differently for /favicon.ico request compared to any other requests (identified more specifically with rekonq string) and I think better it should be the same. I've also suspected request is done by some underlying KDE component but my proxy settings KDE system-wide are same as manual in rekonq. Thanks for developing rekonq Reproducible: Always Steps to Reproduce: 1. configure http proxy settings and use some non-local proxy 2. type URL with some webserver you have access to logs 3. check webserver logs and IP with request GET /favicon - it is not IP of your proxy Actual Results: in webserver access logs IP with GET /favicon issued by rekonq is not IP of your proxy Expected Results: in webserver access logs IP with GET /favicon issued by rekonq MUST be IP of your proxy
You are right. We has design problems to implement a decent favicon retrieve system. I'll try addressing these issues ASAP.
Git commit 7330968510ffd83ab208ae0ffa8febe49c4dbcdb by Andrea Diamantini. Committed on 10/06/2013 at 11:50. Pushed by adjam into branch 'master'. Link custom rekonq QNAM to KDE proxy settings This is a first attempt to link our needed QNAM to KDE proxy settings. It will try to fix proxy problems when used. Oh... I also added some new error strings in case of proxy problems :) Related: bug 315598 M +1 -0 src/CMakeLists.txt M +4 -2 src/icons/icondownloader.cpp A +73 -0 src/webtab/knetworkaccessmanager.cpp [License: GPL (v2/3)] A +46 -0 src/webtab/knetworkaccessmanager.h [License: GPL (v2/3)] M +2 -1 src/webtab/networkaccessmanager.cpp M +32 -0 src/webtab/webpage.cpp http://commits.kde.org/rekonq/7330968510ffd83ab208ae0ffa8febe49c4dbcdb
Development on Rekonq ceased four years ago, and it has been unmaintained since then. KDE recommends using Falkon instead.