Bug #48310 for HTTP-Proxy: Response filters not firing for 0.24

Wed Jul 29 15:31:27 2009 hs [...] activeframe.de - Ticket created

Subject:	Response filters not firing for 0.24
Date:	Wed, 29 Jul 2009 21:31:04 +0200 (CEST)
To:	bug-HTTP-Proxy [...] rt.cpan.org
From:	"Hendrik Schumacher" <hs [...] activeframe.de>

Hi, after updating HTTP::Proxy from 0.23 to 0.24 I still have problems with response filters not firing occasionally (though not as often as with 0.23). I couldnt determine the cause yet, it still seems random to me. But putting the following at the end of the main loop in Proxy.pm / serve_connections() seems to fix the problem for me: $self->{$_}{request}->eod for qw( headers body ); $self->{$_}{response}->eod for qw( headers body ); So it seems that the Response-Filterstack isnt reset properly in all cases and select_filter is skipped during the next request. I run Perl 5.10.0 under Linux 2.6.24-etchnhalf.1-686. Hendrik Schumacher

Sun Jan 03 17:22:17 2010 BOBMATH [...] cpan.org - Correspondence added

On Wed Jul 29 15:31:27 2009, hs@activeframe.de wrote: Show quoted text

> So it seems that the Response-Filterstack isnt reset properly in all cases > and select_filter is skipped during the next request.

This always happens when the server sends an empty response, like a redirect (see http://en.wikipedia.org/ for an example). If the next request from the browser is following the redirect, AND it gets handled by the same proxy process, then it may appear that the proxy is working correctly when in fact it is not. The immediate cause is the if block at Proxy.pm 441, which calls select_filters after filter_last is called, leaving the response body handlers in an incorrect state. The root cause is that serve_connections is a horrible monstrosity that desperately needs to be refactored (goto flow control, srsly?). -bob

Sun Jan 03 17:22:19 2010 The RT System itself - Status changed from 'new' to 'open'

Mon Jan 18 07:07:10 2010 book [...] cpan.org - Correspondence added

On Sun Jan 03 17:22:17 2010, BOBMATH wrote: Show quoted text

> On Wed Jul 29 15:31:27 2009, hs@activeframe.de wrote:

> > So it seems that the Response-Filterstack isnt reset properly in all

> cases

> > and select_filter is skipped during the next request.

> > This always happens when the server sends an empty response, like a > redirect (see http://en.wikipedia.org/ for an example). If the next > request from the browser is following the redirect, AND it gets > handled by the same proxy process, then it may appear that the > proxy is working correctly when in fact it is not.

I think the commit 07757d3ffd295b6e54a81fea0a9f01e3fab58269 does fix this issue. See the github or git.bruhat.net repository. Show quoted text

> The immediate cause is the if block at Proxy.pm 441, which calls > select_filters after filter_last is called, leaving the response > body handlers in an incorrect state. The root cause is that > serve_connections is a horrible monstrosity that desperately needs > to be refactored (goto flow control, srsly?). > > -bob

The refactor I long for is the one that separates the network layer from the data manipulation layers. This would make HTTP::Proxy really useful. Thanks for your help, -- BooK

Mon Jan 18 07:07:34 2010 book [...] cpan.org - Status changed from 'open' to 'resolved'