Http Server: the http header

This is the definition of  the http header class,
This file was taken from the boost example

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: Http request

This patch defines the http request object.
A request is mostly a list of headers.

This file was taken from the boost example

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: reply object

The reply object contains the information,
that will be sent back.

It contins the functionality needed to serilize the data
to the output stream.

It also contains the constant definitions for status code,
and for error messages, that are used when returning an error reply

This file was taken from the boost example

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: mime type

This patch adds the mapping from file extension to mime type.

For example htm would be mapped to text/html

This file was taken from the boost example, and
js and json files where added to it.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: common types

The common files holds types that are common to most files.

The parameters define the parameters object that is passed to a request.

The operation_type, identify if this request is GET or POST

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: request parser

The request parser parse the incoming request buffer
and create a request object.

This file was taken from the boost example

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: handlers

The handlers are the entities that holds the specific logic
to handle a request.

All handlers inherit from handler_base.

There are a few general purpse handlers that their logic
can be reused for different scenarios.

file_handler map a url to a file, i.e. it will ignore any parameters
in the request and would always reply that file.

directory_handler is similiar to a file, but it uses a base directory
e.g. /usr/mgmt and gets a path parameter in the parameters object
it would concat the path to the base dir and would return the file.

both file and directory handle can add an optional file parser.
This is allows file that need to contain the server information,
use a parameter, and the parser would modify the result, so that
the server address apear in it.

function_handler gets a lambda expression as a parameter and uses
it to generate the result.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: matchers

matchers are used in match rules to decide if a url matches
some logic.

For example consider the rule: /file/{path} where path
is a parameter.
This rule would match /file/etc/hosts, but would not match /file1/etc/hosts

A rule that would match this url would be combined from two matchers.
An str_matcher that would match the static part '/file'
And a param_matcher that would match the remaining url ('/etc/hosts')

For param_matcher there are two options:
They can match either a part between slashes
(e.g. for cases /usr/{name}/get) or until the end of the
URL like the /file example above

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: match rule

Match rule check if a given url match some logic, if it does,
it returns the handler assigned to it.

A match rule has a list of matchers, when searching
for a match, it iterate over them.
Each match returns the next position in the url,
a match would also fill the parameters object when needed.

Consider the rule /file/{path} and the url /file/etc/hosts

The match rule would hold a handler and two matcher, an
str_matcher
and a param_matcher.

It would call the first matcher with the url, it would get back
7 (the end position of the match), the parameters object is still
not changed at this point.
It would then call the second matcher that would return the
end of the string position and would fill in the parameter
object, parameters 'path' with value /etc/hosts

As this is the end of the string and there are no more matcher
the match rule would return the handler

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: routes

The routes object holds the dispatching information for
the incoming http reqeust.

It uses either an exact match or a match rules to find a
handler to handle the request based on its URL request.

If no handler is found, a page not found is returned.
If an exception is thrown during the processing of the
handler an internal server error is returned.

The matching is done in two phases, first an exact match
is search for.
For that the routes holds a map of url, if an exact match
is found, its associated handler is returned.

If there is no exact match, a matching rule is searched.
Matching rules are choose by their insertion order.
where the first rules that inserted has the highest priority.

For that, routes holds a vector of matching rules that
is search for a match.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: request_handler

The request handlers gets the request object, parse the url
And use the routes object to handle the request.

This file was taken from the boost example and was modified
to use the routes object

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: connection

connection holds the open socket for the request.
It uses the parser to parse the incoming message and
create a reqeust object from it.

It would use the reply to answer the request and would
close the connection.

This file was taken from the boost example

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: connection_manager

The connection manager is a container for the connections.
It can be used by the server for force connection
termination on exit.

This file was taken from the boost example

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: server

The sever listen to incoming request, when a new request is comming
it call accept and passes the new socket to the connection manager,
which would pass it to a new connection

This file was taken from the boost example

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: main

The main class parse the command line, starts the server and prints
the help if needed

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
[ penberg: cleanups ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: makefile

This patch adds a make file to the http server.

Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Http Server: Show reason if handler throws exceptions

Makes debugging much easier.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>