Version: (using KDE KDE 3.5.1) Installed from: Debian testing/unstable Packages OS: Linux I am using a local apache server for html- and php-development and notice that Opera-9.01 performs much faster than Konqueror. Inspecting apache logs I find: Opera does conditional requests http 304 even when I press ctrl-R. Konqueror either uses cache or does unconditional requests http 200, almost never conditional requests, and this applies to all three possible cache settings. There are some 304-lines in apache logs, but it seems impossible to reproduce conditional requests. A proper cache policy would improve Konquerors performance dramatically!
Updated to KDE-3.5.5 some days ago - issue concerns Konqueror-3.5.5 also.
Updated to KDE-3.5.6 - issue concerns Konqueror-3.5.6 also.
Reload in Konqueror means forced reload, so the entire idea of reload is not to use cache. I think there is a suggestion somewhere to have another soft reload, that just attempts an update. Do you have examples of normal fetching that doesn't use conditional request, or is this about reloading only?
Most important is for me the "default case": simply mouse clicking on href-tags like <a href="http://localhost/somedir/somefile.html">somefile.html</a> Luckily cron.daily has just rotatet apache/access.log and I can start with an empty log file. After setting Konqueror "Enable Cache" and "Use cache if possible", "walking" through 16 html pages of a the local mirror of a small website, once with Konqueror and once with Opera: + cd /var/log/apache + grep -c ' 304 .*Konqueror' access.log 0 + grep -c ' 200 .*Konqueror' access.log 321 + grep -c ' 200 .*Opera' access.log 95 + grep -c ' 304 .*Opera' access.log 700 # .. and after second "walk": $ grep -c ' 200 .*Konqueror' access.log 321 +grep -c ' 304 .*Konqueror' access.log 0 + grep -c ' 200 .*Opera' access.log 96 + grep -c ' 304 .*Opera' access.log 1536 # .. and setting Konqueror to "Keep Cache in Sync" and a third "walk" with Konqueror: + grep -c Konqueror access.log 321 As I wrote initially: Konqueror either uses cache or does unconditional requests resulting in http 200. Currently using 3.5.6, updating to 3.5.7 scheduled but cannot spare the time this days.
For completeness: Another "walk" as described above, with additionally keystroke ctrl-r on each page yields 3422 lines http 200 and 1 line http 404 from non existing /favicon.ico. We see, Konqueror does the job of reloading "rearly perfect". ALL trials to achieve http 304 requests failed. Using Konqueror for html- and css-development is attractive, because among all current html browsers Konqueror is closest to html- and css-standards. Having at least one cache setting, where Konqueror distinguishes modified and unmodified files would be really great. Currently I must either ALWAYS use keystroke ctrl-r or select "Tools - HTML-Settings - Disable Cache". In both cases reloading of ALL refered and imported components is highly inconvenient, because almost every time you have modified only one single file. Summary: There should be at least one cache setting, where Konqueror executes always conditional requests http 304.
SVN commit 848047 by sstjames: Don't force all images to be re-downloaded if softReload is true. Approved by ggarand. The corresponding Konqueror patch that offers a "forced" reload action is awaiting review. This probably isn't a full fix for 137720, but should be of interest to the reporter. CCBUG:137720 M +4 -1 loader.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=848047
SVN commit 868578 by sstjames Add "force reload" action to Konqueror (CTRL+F5 or CTRL+Shift+R by default). This is a companion to r848047. Approved by dfaure.
SVN commit 969350 by ggarand: .use the normal cache policy for all objects during soft reloads, not just for images. This will let KIO use 'If-Modified-Since' conditional queries when appropriate. .don't trust the cache's expiry date when soft-reloading - always send conditional queries to revalidate instead. .only check the completed state of a part when an object that was signaled to be loaded is actually part of our descendant chain. Checking that for ancestors requests (or even other process-wide documents) is wasteful. Shouldn't this check even be limited to objects requested strictly by the document, and not its children? I wonder.. BUG: 137720 M +36 -8 khtml_part.cpp M +1 -4 misc/loader.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=969350