Konqueror and Squid: Stalling of External Viewers

For a workaround, see end of page.

A matter that has annoyed and intrigued me for ages is finally at least identified in its contributing factors: opening files from the web in external viewers from konqueror, when using a (squid) proxy server, causes frequent stalls. KDE bug 169433.

Product: konqueror
Version: 3.5
Platform: Gentoo Packages
OS/Version: Linux

For more than a year I've had the problem that attempts at opening PDF, JPG, DVI, ODT, DOC etc. files from the web have often stalled at just a few percent, but have eventually opened if the link is clicked several more times (and then all the attempts open at once).

Before reporting this, I've made a thorough investigation on two computers on different networks, after removing all config files. The result is that I've identified the problem as occurring WHEN and ONLY WHEN konqueror is configured to open a filetype in an external viewer, e.g. kpdf, kuickshow, AND there is a proxy server.

It doesn't matter which external viewer. The only proxy I've used is squid; at one place it's a transparent proxy in the gateway, and at the other it's configured in konqueror as a http proxy on port 3128. I've had several squid versions during the time of the problem, always taking the latest that gentoo-stable can offer. The problem doesn't occur with any other browser I've tried, e.g. firefox, seamonkey. Loading files into konqueror's embedded viewers never shows the problem. There's no website that I recall as avoiding this problem, as long as the files are quite large, i.e. hundreds of kB or some MB. The problem occurs even with a completely new user account, as soon as the external viewer and proxy server settings are applied.

Even with the proxy present, the problem doesn't always happen, especially if the file is already cached. I did my testing by opening loads of ~500KB--1500KB jpegs in kuickshow from a page full of pictures. With the proxy active, the first few attempts went well, then there were about as many failures and successes after that. Turning off the proxy or turning on embedding allowed tens of successful openings with never a sign of trouble. I tried it a lot of times -- I'd already been trying with loads of other settings such as cache, plugins, etc.

Does this funny combination of circumstances give a hint to any developer as to the difference between downloads to external and embedded viewers? I'd love to have it fixed, but for now, having discovered the combination, I'll turn off proxies. I can't stand the other browsers!


Incidentally, the reason I love konqueror so much is several finesses it has, apart from being set up for its file-associations at the same time as the KDE file-manager is set up.

Try to tell other browsers, e.g. firefox or seamonkey, which program to use to open some sort of file: they'll want a full path to the program, which is a ludicrous way to work. Apart from being a silly waste of time when they ought to do the searching themselves if given a plain command-name, it doesn't even work at all when the home-directory is shared over several computers, possibly with different systems (e.g. some Linux, FreeBSD, Solaris) that put programs in different places.

Try opening instances of seamonkey or firefox on several computers that share the same home directory -- ``this profile is in use''. Actually, that problem turns up sometimes even without multiple computers.

The `up' button, to chop the last file or directory off the end of the URL -- very handy on well-designed sites that have some structure, or to get to the homepage quickly.

And: it's much quicker at starting than those others are. So, I wouldn't give it up just because of the above bug (which might not even be it's fault, technically).


A workaround

Never mind why I tried this: it works anyway ... Instead of using the proxy directly, I've used a tcp connection tunnelled through ssh, i.e.
ssh -N -f -x username@squid.server.name -L 3129:localhost:3128
and have then used localhost:3129 as the proxy server in konqueror (alternatives are to use the -o GatewayPorts=yes option in ssh to allow other computers to access the forwarding computer as a proxy, or just to run the forwarding on the same host as the squid program). This works fine. Something to do with the ssh tunnel always looking open even if squid doesn't always respond immediately? It's nice to have konqueror plus lots of caching again.

Page started: 2008-08-19
Last change: 2009-03-03