hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd W Lainhart <lainh...@us.ibm.com>
Subject Re: Mapping javax.servlet to HttpCore - best practices questions
Date Thu, 05 Feb 2009 21:56:10 GMT
> The Servlet API would take care of incoming connections and 
> HttpCore would be used to transform the incoming request and forward it 
> to the target server? 

That's right.  Imagine an AbstractServlet that implementors would derive 
from, whose service method looked something like this:

service(HttpRequest coreRequest, HttpResponse coreResponse);

The implementor would handle that service method, and then either handle 
the business logic there, or forward to another server (i.e. make an HTTP 
request to another server).  The AbstractServlet's job is to transform the 
HttpServletRequest/Response objects to the HttpCore analogues.

So then the issue becomes, for those clients that are savvy using 
HttpCore, what is their expectation for where to find the data that they 
would normally find in HttpServletRequest?  I'm guessing parameters, and 
not context, but this still isn't clear to me from reading the updated 
tutorial.

  -- Todd






From:
Oleg Kalnichevski <olegk@apache.org>
To:
HttpClient User Discussion <httpclient-users@hc.apache.org>
Date:
02/05/2009 03:41 PM
Subject:
Re: Mapping javax.servlet to HttpCore - best practices questions



Todd W Lainhart wrote:
> Hi Oleg -
> 
> Thanks for the quick response.
> 
> I agree that it seems odd to use the HttpCore abstractions on top of 
> javax.servlet .  Indeed, I wondered if it was just too weird to map the 
> nominally "output" object of HttpRequest to the "input" object of 
> HttpServletRequest that's passed to the service method.  But in the case 

> of where the servlet is acting as a proxy, and just poking that 
> HttpRequest object to resend via HttpCore, there might be some utility 
> there.
> 

Wait a second! If I understand you correctly the servlet in question is 
intended to function as a reverse proxy to some external content 
provider? The Servlet API would take care of incoming connections and 
HttpCore would be used to transform the incoming request and forward it 
to the target server? If this is the case, than there will be no loss of 
efficiency or any issue with content streaming. In fact HttpCore has 
been specifically designed for such use scenarios. Initially I thought 
you were going to abstract away Servler based HTTP transport using 
HttpCore API, which of course could be quite problematic.

Oleg

> The requirement is that the app run in a servlet/WAR, and a goal is to 
> hide/normalize the various servlet implementations behind HttpCore, 
which 
> we feel is a strong enough abstraction to promote first-class through a 
> similar service interface to HttpServlet.service(...) (i.e. using 
> HttpCore's HttpRequest/Response objects instead of 
> HttpServletRequest/Response).  But for reasons described in the first 
> paragraph, and the streaming performance concerns you raise, I wonder if 
a 
> better design would be to provide functions that map between 
> ServletRequest/Response to HttpCore, when that's used on the server.
> 
> I had also wondered about the performance degradation on streaming 
> content.  I thought that I might be able to somehow bridge the 
> outputStream from HttpServletResponse to HttpResponse, but I haven't 
> looked into that yet, or thought that through.
> 
>   -- Todd
> 
> 
> 
> 
> From:
> Oleg Kalnichevski <olegk@apache.org>
> To:
> HttpClient User Discussion <httpclient-users@hc.apache.org>
> Date:
> 02/04/2009 06:23 PM
> Subject:
> Re: Mapping javax.servlet to HttpCore - best practices questions
> 
> 
> 
> Todd W Lainhart wrote:
>> I'm working on a prototype where I hide the HttpServletRequest/Response 

>> objects and the various servlet goo-age behind HttpRequest/Response. 
>> Imagine that a servlet is calling out to a handler of a "service(...)" 
>> where the parameters are HttpRequest/Response, populated by the servlet 

>> prior to calling this handler.  I'm looking for best practices to do 
> this, 
>> based on the design of the HttpCore classes and the expectations of 
>> clients that receive HttpRequest/Response objects.  I've done 
>> "TheGuidedTour..." and read some Javadoc.
>>
> 
> Todd,
> 
> The guided tour is somewhat outdated. There is a more recent and more 
> complete document describing HttpCore API and its intended usage:
> 
> http://hc.apache.org/httpcomponents-core/tutorial/html/
> 
http://hc.apache.org/httpcomponents-core/tutorial/pdf/httpcore-tutorial.pdf

> 
> 
> I'll look into your questions tomorrow in details and try to give you 
> some recommendations. However, I just cannot help wondering what it the 
> reason for trying to put HttpCore on top of a Servlet based transport?
> 
> While HTTP headers may be relatively easy to map, content streaming may 
> be significantly more difficult to achieve without a certain performance 

> degradation.
> 
> Oleg
> 
>> HttpServletRequest headers: These seem straightforward enough - I just 
>> copy these into the headers of the HttpServletRequest.
>>
>> HttpServletRequest parameters: Based on my reading of "GuidedTour..." 
> I'm 
>> guessing that stuff this parameter map into some HttpParams derivation 
>> associated to the HttpRequest, and document the well-known key?
>>
>> HttpServletRequest other data : Likewise, I stuff this data into 
>> HttpParams (either Basic or a specialized derivation)?
>>
>> ServletRequest host info : I grab this data, put it into an HttpHost 
>> object, and associate it to the HttpRequest's HttpContext?
>>
>> In dealing with the HttpResponse when shipping this data back out 
> through 
>> the HttpServletResponse, I think I'm going to want to run the responses 

>> interceptors as well as checking headers.  If both a header and an 
>> interceptor for that header is defined, it looks like I should err-out, 

>> rather than prefer one over the other?
>>
>>   -- Todd
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message