[Filterproxy-devel] Re: FilterProxy-0.30 and upstream auth proxy problem

[Bob M. <mce...@dr...>]

John Straw [joh...@be...] wrote:
> Hello,
>=20
> First, let me say that I really like FilterProxy.  I had been using
> junkbuster for several years, but I was having trouble using it with
> mozilla.  I switched to FilterProxy, and I haven't regretted it.  It's
> much more powerful, and configuration is much easier with the web
> interface.

Glad you like it!

> That said, I have a couple of problems, and I'm wondering if you can
> give me any help.
>=20
> Some information about my setup:
>=20
> * FilterProxy 0.30
> * sparc Solaris 8
> * perl 5.6.1
> * libwww-perl 5.64
> * HTML::MASON 1.04
> * Compress::Zlib 1.16
> * haven't installed XML, XSLT, or ImageMagik modules
>=20
> 1. I've recently been forced to start using an upstream proxy which
> requires authentication -- previously we had an open proxy, which I
> used with no problems.  When I try to submit a web form using the GET
> action, everything is okay.  If the form uses POST, however, I
> immediatly get and error: "500 Can't read entity body: Connection
> reset by peer".
>=20
> This happens with all the browsers I've tried running against
> FilterProxy: mozilla and Netscape 4.78 on my solaris box, IE 5.5 on my
> WinNT box.  The settings for http_proxy_username and
> http_proxy_password appear to make no difference -- the problem occurs
> if I leave them unset, as well.

This is not a configuration I have tested at all.  It might be useful to
use ngrep and/or tcpdump on the machine running FilterProxy to determine
if it is FilterProxy or the upstream proxy that is generating the error.

After filtering FilterProxy hands off the request to LWP, which handles
talking to your upstream proxy.  To determine if it is an LWP or
upstream proxy bug, use the lwp-request program to see if you can get a
POST request through your upstream proxy.  If POST's work with using
only the upstream proxy and your browser, but not lwp-request then the
problem must be in LWP...

> 2. Not as big a deal, but I can only start FilterProxy once per system
> boot.  If I stop FilterProxy for any reason and try to restart it, it
> goes crazy and forks hundreds of perl processes, sucking up all the
> resources on my machine.  I have to reboot before I can run it again.

That is a big deal!

> I've seen a reference to a "infinite fork bomb" in the TODO file -- is
> this the same problem?  Similar?  This is absolutely reproducible for
> me, and I don't understand it at all.

This one?

    Connect to proxy as a web server (not proxied)...cases infinite fork
    bomb.
        See John Waymouth's messages.
        Is this fixed?  I can't reproduce it anymore...

I just tried it and everything seems to work fine when I connect to the
proxy as a regular web server.

But that TODO note doesn't sound like your problem.  I have never
actually seen one of these mythical fork-bomb bugs.  Could you:
    1) Exit/kill FilterProxy and make sure there are no FP processes
    running, by checking manually with ps.  The being-able-to-run-it-
    the-first-time behavior makes me thing that it is still running...

    2) run an strace when you start FilterProxy again.  Use a command
    like this (csh syntax):
        strace ./FilterProxy.pl -n >& FilterProxy.strace.log
    the -n will keep it attached to the terminal it started from, and
    you should be able to kill it with ctrl-c.

    3) send me the strace.log, or put it up for ftp/http if it's big or
    something.

If Solaris doesn't have strace, see if it has something similar...(under
linux strace dumps system calls to stdout with their args)

> I hope that you can give me some sort of insight into these two
> problems.  I don't speak much perl, but I'll happily pitch in as much
> as I can if you think it will help to clear things up.

Thanks.  ;)

Cheers,
-- Bob

Bob McElrath (rsm...@st...)=20
Univ. of Wisconsin at Madison, Department of Physics