============================================================
 FlyingHttpServer - lightweight HTTP server based on C++
 'http' - HTTP related classes documentation
------------------------------------------------------------
                                               by smg_ykz
============================================================

1. Introduction

This 'http' sub-directory attempts to provide some useful class libraries
for the purpose of realizing the very HTTP server functionality. This documentation
tries to address its design concept etc..

2. Overview

Once any accepted socket become available to be read, received data parsing should be
processed immediately. It is supposed to instantiate some object to represent its parsing state.
This parsing object might be better to behave as some Factory method where the instantiated
object is responsible for the very request handling.

<Typical sequences (draft idea)>

[Parsing object].parse(<some object which help to read data>);
[Parsing object].isComplete()
 -> In case of 'false', the business logic once again try to wait for the socket so that another
    parse operation can be resumed shortly.
 -> In case of 'true', it is supposed to instantiate 'request handler' to process its request further.

mt::AutoPtr<RequestHandler> handler = [Parsing object].createRequestHandler();
 This handler have to deal with giving response to the peer etc.. So in that sense, it must have
 its network socket information.

 Once the request handler on the above finishes its requested action (e.g. getting file or doing some
 CGI (Common Gateway Interface) action), it is common that the network socket is again reused for
 the other purpose. Assume that we have some manager class to take control of such accepted network
 sockets (let's say it as 'SocketManager' class). Then it should be better for such 'SocketManager'
 class object to continue to watch the status of the network socket even after the request handler
 creation... To do so, what the 'parser' object is supposed to would be as follows.

 after performing craeteReqeustHandler(), the 'parser' object has to once release its network socket
 watching (cm::Event::tsdInstance().delHandlerRead(...)) and then delegates its process to the 'request
 handler' object, although we are not sure of what kind of cases are there...

 After the 'request handler' finishes its operation, then it is supposed to notify someone

[Issues to be addressed] How to deal with authentication? -> Authentication configuration basically
be per requested resource basis, it might be better to be handled in Request handler phase...
However, it might not be always the case.  We may need to carefully come to think of whether
some other case is there.


