You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Todd W Lainhart <la...@us.ibm.com> on 2009/02/04 22:29:45 UTC
Mapping javax.servlet to HttpCore - best practices questions
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.
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
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Todd W Lainhart <la...@us.ibm.com>.
Thanks Oleg - this will be very helpful.
-- Todd
From:
Oleg Kalnichevski <ol...@apache.org>
To:
HttpClient User Discussion <ht...@hc.apache.org>
Date:
02/06/2009 11:09 AM
Subject:
Re: Mapping javax.servlet to HttpCore - best practices questions
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 <ol...@apache.org>
> To:
> HttpClient User Discussion <ht...@hc.apache.org>
> 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: 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
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@apache.org>
> To:
> HttpClient User Discussion <ht...@hc.apache.org>
> 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: 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
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Todd W Lainhart <la...@us.ibm.com>.
>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.
-- Todd
From:
Oleg Kalnichevski <ol...@apache.org>
To:
HttpClient User Discussion <ht...@hc.apache.org>
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: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Todd W Lainhart <la...@us.ibm.com>.
> 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 <ol...@apache.org>
To:
HttpClient User Discussion <ht...@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 <ol...@apache.org>
> To:
> HttpClient User Discussion <ht...@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
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@apache.org>
> To:
> HttpClient User Discussion <ht...@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
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Todd W Lainhart <la...@us.ibm.com>.
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 <ol...@apache.org>
To:
HttpClient User Discussion <ht...@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
Re: Mapping javax.servlet to HttpCore - best practices questions
Posted by Oleg Kalnichevski <ol...@apache.org>.
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