Skip Menu |
 

This queue is for tickets about the HTTP-Proxy CPAN distribution.

Report information
The Basics
Id: 48310
Status: resolved
Priority: 0/
Queue: HTTP-Proxy

People
Owner: Nobody in particular
Requestors: hs [...] activeframe.de
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



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>
Download (untitled) / with headers
text/plain 649b
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
Download (untitled) / with headers
text/plain 813b
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
Download (untitled) / with headers
text/plain 1.1k
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.