By oleksiys on Mar 15, 2010
We've completed initial implementation of the Grizzly 2.0 HTTP module. The main different with the Grizzly 1.x - is that we separated HTTP parsing and processing logic, so HTTP module has 2 HttpFilter implementations: client and server, which are responsible for asynchronous parsing/serializing of HTTP messages. So developer will be responsible for implementing just the HTTP processing logic. Here is general schema of HTTP message processing:
(read phase): TransportFilter - (Buffer) -> [SSLFilter] - (Buffer) -> HttpFilter - (HttpContent) -> CustomHttpProcessorFilter
(write phase): CustomHttpProcessorFilter - (HttpPacket) -> HttpFilter - (Buffer) -> [SSLFilter] - (Buffer) -> TransportFilter
The big advantage of the Filter approach - is that it's possible to reuse HttpFilter logic for both HTTP client and HTTP server code.
I've also created a sample, which includes:
1) \*Simple Web server, which is implemented as custom Grizzly 2.0 Filter, and is able to serve HTTP requests for the static resources (local files).
2) \*Simple HTTP client, which downloads remote HTTP resource to the local file.
The next step for Grizzly 2.0 is to simplify Web server and HTTP client development by providing higher level API. On server side it will be similar GrizzlyWebServer/GrizzlyAdapter/GrizzlyRequest/GrizzlyResponse API, known from Grizzly 1.9.x and as for client side we will also need to come with some reasonable API.
Feedback is very appreciated.
\* Just a small note, that both server and client are operating in non-blocking mode.