On Mon, Sep 27, 2010 at 11:51 PM, Markus F.
[email protected]wrote:
Hi!
On 28.09.2010 01:16, John W Higgins wrote:
Transparent or Intercepting - GitHub - igrigorik/em-proxy: EventMachine Proxy DSL for writing high-performance transparent / intercepting proxies in Ruby
This one looks very promising based on the slides and the documentation.
However I’ve instantly ran into troubles outlined here:
Issues · igrigorik/em-proxy · GitHub . Any idea?
I would chalk it up to probably just a mistake in the sample code - yes,
it’s not the best first impression but it does happen. It may very well
be
conn.unbind instead of unbind but I’m not certain (unbind is a method of
the
connection object).
Another thing I’m not sure: when I look at the simply forwarding example
in the README.rdoc, I see that I basically have hook methods (on_data,
on_response, etc.) onto which I can attach my own code.
What I would need is a per client/connection logic. I.e. a client
connects, I inspect and forward the traffic. I also my intercept some
requests from the client and send back my own stuff. Ultimately I have a
state per client.
Try looking at the smtp_whitelist example. It shows intercepting a
request -
looking at it and sending back a response without the proxy actually
passing
it on to the backend server. If you return nil from the on_data call
then
nothing is forwarded along.
You do have a state - the “conn” object, which EventMachine creates per
connection and passes into the outer block that then calls into the
on_data,
on_response et al. blocks.
My guess for your case would be that you would want to extend the
connection
class (see connection.rb) to hold more information that would be
available
to you during the lifetime of the connection.
If nothing else this is around 200 or so lines of code that gives a nice
starting point to anything more custom that you believe you would
need/want.
I would be rather impressed if something else gave you more flexibility
than
this and lived in the ruby world. You may find very well that a few
helper
methods would help you along the way or perhaps the opposite in that you
don’t want the blocks but rather to work in a custom connection object
that
eliminates the block calls. But I do assure you that this is the right
road
to be on…
John