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. 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 <[email protected]> To: HttpClient User Discussion <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
