On Fri, Oct 04, 2002 at 10:22:34AM -0700, Peter Guzis wrote:
> Is there a way (supported or a hack) to find out what *filtered* data is
> waiting to be posted to a POE::Wheel::ReadWrite InputEvent?
Filters should not hold filtered data. Rather, they should hold raw
data and filter a single record for each InputEvent callback. This is
implemented with the get_one_start() and get_one() methods.
The get_one_start() method accepts raw stream data and places it in
the filter's framing buffer. The data is not altered in any way
during this call.
The get_one() method parses a single record from the start of the
filter's framing buffer and returns it.
Using these two methods ensures that a filter only contains raw data,
and it enables get_pending() to return that raw data.
Generally speaking, it's hardly ever necessary to call get_pending()
yourself. Wheel::ReadWrite's set_input_filter() method will call it
for you while it switches filters.
If set_input_filter() fails, please post a small, self-contained test
case to POE's bug tracker. The ability to switch filters is a
fundamental feature, and it is imperative that it works correctly.
> At my workplace, we have an HTTP proxy that requires NTLM authentication.
> This works great for Internet Explorer users, but Netscape and Mac users
> (and just about everyone else) are left in the cold. I have started a
> project to make a proxy server that works like such:
>
> 1. Client makes HTTP request to my proxy server and sends basic credentials
> 2. Proxy forwards request to upstream proxy and replaces basic credentials
> with NTLM handshake
> 3. Upstream proxy sends back NTLM challenge
> 4. Proxy sends back NTLM response
> 5. Upstream proxy sends back either an HTTP code 407 (Proxy Authorization
> Required) or the requested page.
>
> In order for the NTLM authentication to work, the connection to the upstream
> proxy must be kept alive during steps 2-5. This means that elegant
> solutions like PoCo::Client::HTTP are out of the question since they
> explicitly terminate the connection after each request.
It is not a design goal for PoCo::Client::HTTP to close connections
after a response. It's just that nobody who knows how to support
keep-alive has stepped up to add the feature. I will be happy to add
the feature if anyone needs it and can add it.
> I have had moderate success in setting this up using POE and a mix of both
> POE::Filter::Line and POE::Filter::Block. I know switching filters
> mid-stream can be tricky and have already attempted to compensate for this
> by using $heap->{'readwrite'}->get_input_filter->get_pending just prior to
> switching filters. However, get_pending doesn't tell me anything about the
> lines queued for posting to my InputEvent. If I switch filters after
> receiving a blank HTTP header line and some of the HTML content was also
> slurped into Filter::Line, I end up receiving my get_pending data before the
> other content.
>
> Any help would be greatly appreciated.
See above. :) Switching filters shouldn't be tricky in recent Perl
versions. Perhaps you have an older one? If you installed it via
ActiveState's PPM utility, you may have downloaded version 0.09 or
0.12, both of which are more than two years old. Check your POE
version with this (use single- instead of double-quotes for UNIX):
perl -MPOE -e "print $POE::VERSION"
If it's anything less than 0.23, you can find instructions for
downloading the most recent one at:
http://poe.perl.org/?Where_to_Get_POE
Good luck!
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
