On January 6, 2007 Jeff Pohlmeyer awoke from hibernation and
slithered from beneath a rock to the sound of Daniel Stenberg:

> Do you still experience these problems? If so, I'm interested in
> getting my hands on that source code (with some usage instructions)
> to see what I can do about it.

Oh yeah, that thing...

I just tried again with this morning's libcurl from CVS and yes,
the problem is still there.

The source code is attached. Operation should be fairly straight forward,
but in order to really stress-test the app, you may need to bump up
your Firefox connection settings.

You can do that by editing the file ~/.mozilla/firefox/*.default/user.js
and adding these three lines:

  user_pref("network.http.max-connections", 255);
  user_pref("network.http.max-connections-per-server", 255);
  user_pref("network.http.max-persistent-connections-per-proxy", 255);

 - And then restart Firefox.

Or just type "about:config" in the Firefox address bar and then
type "network.http.max" in the search box. Then double-click on
each of the three settings to change its value.

255 is probably overkill, but even with it set that high I don't
think I've ever seen more than fifty or so active connections.

Of course, you'll also need to tell Firefox to use the proxy,
e.g. :
  Edit -> Preferences -> Advanced -> Connection Settings ->
    Manual Proxy -> HTTP Proxy -> 127.0.0.1 port 8080
(Or whatever interface and port you choose to start the proxy on)

Just leave the SSL/FTP/Gopher/Socks fields blank, the proxy doesn't
support them anyway.

Here's a handy extension for switching the proxy settings on and off:
  https://addons.mozilla.org/firefox/1557/

And for clearing the browser cache:
  https://addons.mozilla.org/firefox/1881/

The crash seems to happen mostly when the user clicks on a link before
the current page finishes loading, suddenly the proxy ends up with
broken sockets on all the half-loaded images for the current page.
These are the sockets that connect the browser to the proxy, not
the "curl" sockets, but libcurl gets notified of this by returning
zero from any pending write or header callbacks.

At the same time, the browser starts issuing requests for the new stuff,
which in the case of images, could quite possibly be duplicates of
the just-aborted requests. So maybe that's where the free'd connections
end up getting recycled?

I have tried this proxy on probably hundreds of different websites
and it nearly always works perfectly, so the problem might not be
so easy to reproduce.

Lycos.com sometimes causes the crash, but the main offender is
http://www.cephbase.utmb.edu/

Clicking around a few times on that site while the pages are still
loading nearly always causes the crash, but I hate to keep hammering
on a public service website just to debug my program.

Looking forward to your findings,

 - Jeff