Greetings all,
I'm relatively new to POE and, this being my first post to the list,
I'd like to begin with major kudos to its creators. It's an impressive
piece of work in terms of quality, completeness, and ease of use, and
it's helping me do things that would be a lot of work by other means.
On to the question ...
I'm building a proxy server that inspects and acts upon all the HTTP
traffic that goes through it. It's important that a single server
instance be able to handle both HTTP and HTTPS proxy requests, and that
the HTTPS requests be unencrypted on the way through (in contravention
of the usual hands-off approach required of HTTPS proxies).
The protocol (in case you're not intimately familiar with it) is that
the client makes a CONNECT HTTP request, specifying a host:port to
connect to. Upon receiving a success response, the client then begins
sending SSL traffic over the same connection. The proxy is meant to
simply relay traffic between the endpoints, which subsequently negotiate
an SSL connection.
In a nutshell, here is how I'm handling it. I'm using PoCo::Server:TCP
with an Acceptor state. For each new connection, the Acceptor squirrels
away the raw socket handle, then creates a new session that equips
itself with a ReadWrite wheel and an HTTPD filter. (I'm using a custom
Acceptor rather than the Client* handlers because I need access to that
raw socket later on -- can I get to it by other means?)
The socket is then subject to the following abuse:
- read the CONNECT request through the original Wheel
- send a response through the same Wheel and await the FlushedEvent
- when the FlushedEvent is triggered, the first wheel is
shut down, the original socket handle (which is still
connected to the client) is tied to a PoCo::Server::HTTP::SSL
instance (*), and the tied handle is wrapped with a new
ReadWrite wheel and HTTPD filter
Is there a critical race here where the client may respond with the
first bytes of SSL traffic before the original wheel is shut down,
or is this done synchronously while the flushed data is in transit?
Is there a better way to handle it? In any case, it seems to work
reliably.
- the HTTPS request arrives through the new wheel and can then be handled
in (almost) exactly the way as non-SSL proxy requests
(*) PoCo::Server::HTTP::SSL is a new derivative of
PoCo::Client::HTTP::SSL. It differs in that it overrides the
TIEHANDLE method (inherited from Net::SSLeay::Handle) with one that
does an ssl_accept() rather than an ssl_connect().
Is this reasonable? Has anyone done something similar before?
One other problem ...
When the new Wheel with the SSL-tied socket is reading the subsequent
request from the client, it gets through the SSL handshake okay and
reads the first block of data, but it usually gets stuck somewhere
before the remainder of the request data is read (it always succeeds if
the request fits in a single block). The first chunk of data makes its
way through the HTTPD filter, but sysread() is not subsequently called
from Driver::SysRW::get(). I can work around this by creating SysRW with
a sufficiently large block size, but I'd like to avoid arbitrarily
limiting the size of request I can handle.
Any ideas?
GAK! This is long winded! My apologies for that. I'll appreciate
whatever advice you can offer, however brief.
Scott
--
Scott Flinn
+=====================================================================
| Research Officer, Human Web Group
| National Research Council Canada
| Institute for Information Technology -- e-Business
| 46 Dineen Drive, Fredericton, New Brunswick
| Canada, E3B 9W4
+---------------------------------------------------------------------
| E-mail: [EMAIL PROTECTED]
| (506)451-2567 Fax (506)444-6114
| Website: www.iit.nrc.gc.ca
+=====================================================================
| Agent de recherche, Web humain
| Conseil national de recherches Canada
| Institut de technologie de l'information -- Affaires électroniques
| 46, promenade Dineen, Fredericton, Nouveau-Brunswick
| Canada, E3B 9W4
+---------------------------------------------------------------------
| Courrier électronique: [EMAIL PROTECTED]
| (506)451-2567 Docufax (506)444-6114
| Site web: www.iti.cnrc.gc.ca
+=====================================================================
