Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Subject: Re: [HttpCore] example of a reverse HTTP proxy based on HttpCore
	NIO
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <httpcomponents-dev@jakarta.apache.org>
In-Reply-To: <4653755C.20009@khelekore.org>
References: <1179869641.5771.31.camel@okhost> <4653755C.20009@khelekore.org>
Content-Type: text/plain
Date: Wed, 23 May 2007 11:29:36 +0200
Message-Id: <1179912576.5734.19.camel@okhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2007-05-23 at 00:57 +0200, Robert Olofsson wrote:
> Oleg Kalnichevski wrote:
> > I developed a sample application demonstrating how HttpCore NIO can be
> > used to put together a simple reverse HTTP proxy, which nonetheless can
> > handle an arbitrary number of simultaneous connections with as little as
> > two I/O threads.
> 
> Sorry to dissapoint, but I find that hard to believe. Now I may have 
> missed something, but still. Which thread do dns lookups?
> Do you use any non blocking dns library for this proxy?
> 

Hi Robert

Thanks you for your comments. This application was never meant to be a
full-fledged HTTP proxy. It is merely an example of how HttpCore NIO API
could be used for development of asynchronous HTTP services in a
resource efficient manner. 

I never claimed the proxy was fully non-blocking. I am aware DNS lookups
can block I/O threads. Non-blocking domain name resolution is however
out of the project scope.


> InetAddress.getByName is a method that is native and single threaded and
> it is a method that can block for a long time. How it behaves depend on
> the operating system and system libraries. For my proxy I have a
> pluggable system for dns lookups, the default is the dnsjava library,
> but on MS windows InetAddress seems to cause less problems.
> 
> > As always, code reviews, comments, ideas or critique will be greatly
> > appreciated.
> 
> Looking at the proxy parts on a higher level I also find a few problems.
> Most of these problems will  not cause any problems for nice clients, 
> like IE or Firefox, but other clients may cause problems.
>
> One thing that seems to be broken is the handling of hop headers:
> Connection,Proxy-Connection,Keep-Alive,Public,Transfer-Encoding,
> Upgrade,Proxy-Authorization,TE,Proxy-Authenticate,Trailer are all hop
> headers and needs to be removed from one request, I did not find that
> happening in the code. A few of the headers seems to be handled.
> 
> If you want to follow the rfc correctly you also have to make sure you
> have a Host and a Date header in the request if you do HTTP/1.1 request
> (which it looks like). Well, actually it looks like you forward the
> client request version and that is not correct according to the rfc, you
> have to set the http request version to the one the proxy handles, so
> that looks like a violation of the rfc.
> 
> I am also not sure how you handle chunked response and forwarding to a
> HTTP/1.0 client, but I have not really tried to figure that out.
> Many HTTP/1.1 servers will send chunked data when given a HTTP/1.1
> request.
> 

I never claimed the proxy was fully HTTP spec compliant. I intentionally
reduced HTTP protocol handling to an absolute bare minimum. My main goal
was to demonstrate that HttpCore API was flexible enough to deal with
complex scenarios such as HTTP request routing. That is it. 

Cheers

Oleg

> I have only looked at the code for a few minutes so I have probably
> missed many things.
> 
> /robo
> 


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org