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