Bad news: My local copy has gone. I can't find it anymore from my disk. *sigh* Here's what I have been doing to implement HTTP on top of Netty. 1) A codec is basically an implementation of the ChannelHandler interface. Therefore, HTTP codec classes should be placed in the org.jboss.netty.handler.codec.http package. 2) We should have at least three types: HttpRequest, HttpResponse and HttpMethod. HttpMethod should be an enum of all available HTTP methods like GET, POST, etc. HttpRequest and HttpResponse will represent an actual HTTP request and response respectively. They will provide essential getters that are required to implement an HTTP server and client. (We could add some convenience access methods like cookie accessors, but that's another story.) According to the HTTP spec, HTTP request and respose share a couple properties such as header, and therefore it would be a better idea to start from a super interface whose name is 'HttpMessage' IMHO. 3) There's no need to implement HTTP codec to support large chunk of data directly, which means a HttpRequest.getContent() can just return a complete ChannelBuffer instead of a special stream type. However, Chunked encoding should be supported instead to enable COMET, which will eventually allow us to use HTTP as a connection-oriented socket. (Bill Burke is also interested in this.) Supporting chunked encoding is an interesting problem though because the codec should generate additional messages to encode or decode the chunk which is not first. Probably we will need a new type to support chunked encoding, such as 'HttpChunk' and let the user (higher level HTTP client/server implementor) maintain the state by oneself. Once, this codec is ready, I think implementing a highly customized HTTP server shouldn't be difficult at all. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183749#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...