You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Patrick Lightbody <pa...@lightbody.net> on 2011/09/09 17:29:31 UTC
NHttpReverseProxy.java
Thanks for sharing the new async stuff. I'm curious about the example you linked to: NHttpReverseProxy.java.
Can you share a bit more about what that does exactly? I always get a bit confused when talk of "proxies" and "reverse proxies" come up. I ask because I have an open source project that is using an old Jetty 5 proxy (w/ mods) that was capable of doing SSL man-in-the-middle proxying (provided your browser had a special CA installed). Wondering if we might be able to simplify the codebase with some of the stuff you've been working on!
http://opensource.webmetrics.com/browsermob-proxy
Patrick
--
Patrick Lightbody
+1 (415) 830-5488
Schedule a meeting with me at http://lightbody.net/schedule
Re: NHttpReverseProxy.java
Posted by Patrick Lightbody <pa...@lightbody.net>.
Got it - thanks! Our performance requirements aren't that high, so perhaps we'll leave BrowserMob Proxy alone for now.
On Sep 9, 2011, at 10:10 AM, Oleg Kalnichevski wrote:
> On Fri, 2011-09-09 at 08:29 -0700, Patrick Lightbody wrote:
>> Thanks for sharing the new async stuff. I'm curious about the example you linked to: NHttpReverseProxy.java.
>>
>> Can you share a bit more about what that does exactly?
>
> You can point NHttpReverseProxy at an external site (say www.apache.org)
> and use a browser to access content of the target server through the
> proxy. The client (browser) does not even need to know that the site it
> is interacting with is actually a proxy. Hence the term reverse proxy.
>
>
>> I always get a bit confused when talk of "proxies" and "reverse proxies" come up. I ask because I have an open source project that is using an old Jetty 5 proxy (w/ mods) that was capable of doing SSL man-in-the-middle proxying (provided your browser had a special CA installed). Wondering if we might be able to simplify the codebase with some of the stuff you've been working on!
>>
>
> Proxies based on an async I/O model may be better suited for handling
> very large number of connections most of which stay idle most of the
> time. However, if you need to handle data transferred through the proxy
> using standard InputStream / OutputStream abstraction the asynchronous
> I/O model immediately becomes a royal pain in the rectum. You'll be much
> better off using a servlet engine such as Jetty if your proxy is
> intended to handle only a fairly moderate number of concurrent
> connections (<500) and its content processing logic is based on
> InputStream / OutputStream abstraction.
>
> Hope this helps
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: NHttpReverseProxy.java
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2011-09-09 at 08:29 -0700, Patrick Lightbody wrote:
> Thanks for sharing the new async stuff. I'm curious about the example you linked to: NHttpReverseProxy.java.
>
> Can you share a bit more about what that does exactly?
You can point NHttpReverseProxy at an external site (say www.apache.org)
and use a browser to access content of the target server through the
proxy. The client (browser) does not even need to know that the site it
is interacting with is actually a proxy. Hence the term reverse proxy.
> I always get a bit confused when talk of "proxies" and "reverse proxies" come up. I ask because I have an open source project that is using an old Jetty 5 proxy (w/ mods) that was capable of doing SSL man-in-the-middle proxying (provided your browser had a special CA installed). Wondering if we might be able to simplify the codebase with some of the stuff you've been working on!
>
Proxies based on an async I/O model may be better suited for handling
very large number of connections most of which stay idle most of the
time. However, if you need to handle data transferred through the proxy
using standard InputStream / OutputStream abstraction the asynchronous
I/O model immediately becomes a royal pain in the rectum. You'll be much
better off using a servlet engine such as Jetty if your proxy is
intended to handle only a fairly moderate number of concurrent
connections (<500) and its content processing logic is based on
InputStream / OutputStream abstraction.
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org