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: json_element

This patch adds the ability to handle json objects.

The basic building block of a json object is an element.

The base class for all json element is the json_base_element,
that has a name and two flags to state if this element is mandatory
and if this element was set.

From json_base_element, there are two inherited classes, the json_element
which is a template for types.

And the json_list which is a list of elements.
It is up to the inherit class to set the the flag when their value
is set.

The json element uses the json parser to format their value in a
json maner.

json objects are objects that all their members are json elements.
All json object inherit from json_base.

the json base holds a vector with pointers to all object memebers.

This way, an inherit class, add its field to the vector allowing
the json base to itertate over them. This is similiar to reflection
in other languages.

json classes are auto generated from the json swagger definition
file during compilation.

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

json path holds information about path definition.
path definition contained the information required
from an external client to reach some action.

Those action are identified by a nickname.
A path object holds the path (url) the http action (GET/PUT)
and path parameters.

The json path is updated when the json swagger files are parssed,
in the auto code generation that also creates the json files

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: handlers implementation

handlers implementation adds specific logic for specific cases.

Currently it contains the file information handler, that
get a path to a file or directory and returns information on it

handler implementation also contains the initilization part of the routes.
This is where handlers are subscribed to routes

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

The param_replace infrastructure does not exist in the tree so remove
usage of them to fix broken build.

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: json2code parser

The python script reads the swagger json definition
and creates the json objects and json path.
It creates a header and a path definition file for each swagger file

All of its configuration can be override from command line.

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