HTTP protocol execution framework.
Apart from simply sending and receiving messages, there are a lot
of things to consider when communicating with HTTP. Many details
such as transport encodings or connection management are handled
by setting up or interpreting
headers in the messages.
In order to relieve applications from the responsibility of
implementing these nitty-gritty details of the protocol,
HTTP components provides an execution framework that sets up
some of the headers before sending a message, and interprets
headers when a message has been received.
typically keeps lists of so-called interceptors that will be executed
before a message is sent and after it has been received.
An application should initialize a processor, set up the lists
with the required and desired processors, and then communicate
through that processor. There are four kinds of interceptors,
depending on whether they act on
on the client or server side:
|Request||prepares headers before a request is sent||interprets headers when a request is received|
|Response||interprets headers when a response is received||prepares headers before a response is sent|
is a processor for the client side,
for the server side.
On the client side, a
is used to tie together a request, the response to it, and other data
that might be associated with the request execution. It is passed to
the request executor whenever needed.
Information about required and recommended interceptors for the client side will be provided elsewhere. For the time being, please refer to the comments in the example applications or ask on one of the mailing lists.
If you want to develop a server-side application, we recommend that
you implement your application as a servlet running in a servlet engine
like Tomcat or full-blown
JSEE container like Geronimo.
If you prefer to implement a server-side application based on our
assume that you know what you're doing and that you don't need
help in figuring out which interceptors need to be configured.