On Thu, 2009-02-05 at 19:00 -0500, Todd W Lainhart wrote: > >The distinction is quite simple. Use HTTP context for objects that > >represent session data and can be mutable in the course of the request > >processing. HTTP context is somewhat similar to the attribute collection > >of ServletRequest. Use HTTP parameters for simple objects that define > >behavior of the components and are immutable. The closest Servlet > >equivalent I can think of is ServletContext / ServletConfig. > > This was very helpful - thanks. I'm now recalling that the documentation > calls out this role for HTTP Context. Your reply re/ > ServletContext/Config tells me that the stuff I had planned on gleaning > from the ServletContext should go in the params, as I was originally > inclined. > > For the access of these params, I'm using the same idiom as core, which is > to define a IFooPname interface for hanging the map keys off of, and a > FooParam class with a bunch of static convenience methods for accessing > those params. I had planned on deriving from HttpProtocolParams, but > didn't go there because it's final, and because I'm not sure that's a > cohesive binding anyway. > > Thanks! If you do put together a reverse proxy tutorial, I'll be sure to > read it, and structure my approach along its lines. >
Here is an example of a _very_ rudimentary HTTP reverse proxy based on HttpCore (blocking I/O) http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/module-main/src/examples/org/apache/http/examples/ElementalReverseProxy.java Comments, suggestions, critique are welcome. Cheers Oleg > -- Todd > > > > > > > From: > Oleg Kalnichevski <[email protected]> > To: > HttpClient User Discussion <[email protected]> > Date: > 02/05/2009 05:46 PM > Subject: > Re: Mapping javax.servlet to HttpCore - best practices questions > > > > Todd W Lainhart wrote: > >> 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. > > > > Sounds reasonable. > > > 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. > > > > The distinction is quite simple. Use HTTP context for objects that > represent session data and can be mutable in the course of the request > processing. HTTP context is somewhat similar to the attribute collection > of ServletRequest. Use HTTP parameters for simple objects that define > behavior of the components and are immutable. The closest Servlet > equivalent I can think of is ServletContext / ServletConfig. > > I'll try to put together an example of a simple reverse proxy using > HttpCore (classic I/O) in the coming days. Maybe you'll find it useful. > > Hope this helps. > > Oleg > > > -- Todd > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
