This runs the file transformer on a file before returning the result.
This is used for templating support.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The parameters in the request holds the path parameters. The current
implementation based on unorder_map has a few downside:
1. Because path parameters are sometime used to mark a file path and
they can extend to multiple url section (may contain /) the value will
always contain the leading slash. Though this is true for files, for
the common case, it would be easier to return the value without it.
2. The []operator of the hash map is non const, this mean that it cannot
be used in the common case where the request object is passed as a const
reference.
3. There is no exists method in an ordered_map - Usually query
parameters are mandatory, still it is usefull to have an easy way of
testing if a parameter is found.
This series wrap the unordered_map implementation in a manner more
suitable for the request.
The [] operator will be const and retrun a copy of the parameter value
without the leading slash.
The at method will keep the old meaning. For clearer code, a path method
was added to indicate that the return value has a leading slash.
A set method is used for assignment.
Older code will continue to work without changes.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Our input_stream::consume() mechanism allows feeding data from an input
stream into a consumer, piece by piece, until the consumer doesn't want
any more. It currently assumed the input can block (when reading from disk),
but the consumption is assumed to be immediate. This patch adds support for
blocking in the consumption function: The consumer now returns a future
which it promises to fulfill after consuming the given buffer.
This patch goes further by somewhat simplifying (?) the interface of the
consumer. Instead of receiving a mysterious "done" lambda the consumer
is supposed to call when done (doesn't want any more input), the consumer
now returns a future<optional<temporary_buffer<char>>, which means:
1. The future is fulfilled when the consumer is done with this buffer
and either wants more - or wants to stop.
2. If the consumer wants to stop, it returns the *remaining* part of the
buffer it didn't want to process (this will be pushed back into the
input stream).
3. If the consumer is not done, and wants to consume more, it returns an
unset optional.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Obviously, I was sleeping or something when I wrote the reg/unreg code, since
using copy semantics for anchors is equivalent with double unregistrations.
Luckily, unregister was broken as well, so counters did stay active. Which
however broke things once actual non-persistent counters were added. Doh.
* Anchors must be non-copyable
* Above makes creating std::vector<registration> from initializer list
tricky, so added helper type "registrations" which inherits vector<reg>
but constructs from initializer_list<type_instance_id>, avoiding illegal
copying.
* Both register and unregister were broken (map semantics does not overwrite
on insert, only [] or iterator operation).
* Modified the various registration callsites to use registrations and move
semantics.
When using the set_routes with the registry builder, the shared_ptr of
the registry builder should be captured.
In the original implementation the api_registery_builder captured this
parameter, but as the shared_ptr was not captured it was deleted,
causing the http to crash when running in debug.
In this implementation the method that use the registry creates a lambda
function and inside it calls the set_api_doc method, this allows to
catch the shared_ptr so it lives until the function complete.
It also replaces the c style cast to static_cast and add a FIXME note to
the routes implementation, that handlers should be deleted to prevent
memory leak.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
When serving a request with multiple query parameters the last parameter
was parsed incorectly.
This fix the issue and add a test to verify it
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
This is a migration of the api_docs from OSv. It replaces the static
api-doc.json with a dynamic generated reply, this allows to register API
in run time.
The api_registry_builder is a helper class that holds the file and api
path, simplifying registring both the api_doc handler and registering
additional API.
To use the api_doc, first generate a api_registry_builder.
The registry supply two functions, one for registring the api_doc
handler and one for registering an API.
Both function are passed as an argument for the set_routes method of the
http_server_control object.
To find the handler, the get_exact_match in the routes object was needed
to become public.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
There are multiple tasks that need to be performed when setting and
running an http server, specifically the routes need to be set and the
server need to be start.
The server control wrap the server initiation functionality and adds an
iteration function for all routes.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Files transformers are used to replace file content before retrieving
it. Specifically, it is used to return swagger definition files with the
host and protocol replaced.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Function handler in general and json function in particular are the
easiest way to add logic to to handler.
While in some cases the method can return immediately, there are cases
when it is required to perform an async operation, to support those
cases, the function handler was modified to use future.
If it receives an old style function, it would wrap the results in a
make_ready_future. This you could still assign a function like:
new function_handler([](const_req req) {
return "hello";
});
It would no also support a function that return a future json so it is
no possible to assign logic like:
new function_handler([](std::unique_ptr<request> req) {
return make_ready_future<json::json_return_type>("json-future");
});
For the future case note that auto-boxing still works, although you now
need to use make_ready_future.
The json_path was also modified to accept the new kind of function, to
support the common case of route definition based on the code
generation.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Json path are used when parsing the swagger files. Each path represent
an operation in the swagger files.
They are used to simplified setting a handler or a function to a path.
For example: the code generation would define a json_path like:
path_description hello_world("/hello/world",GET,"hello_world", {},{});
Now to define the handler that would use hello_world, you can simply do:
hello_world.set(r,
[](const_req req) {
return "hello world";
});
When r is a reference to a route object.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
File handlers support reading local file and return it as the result
for the http request.
There are two kind of handler, a file handler will return a specific
file when called. A directory handler expect to find a path parameter
called 'path' and would concatinate this parameter to the direcoty path.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Http url encode query parameters by adding a question mark after the uri
with pairs of key=value items.
All values in the url are url decoded.
This add the url encoding and query parameters support
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Most of the time, implementing an http handler consist of a small amount
of logic.
Function handlers are a simplified way of adding such a logic, they
accept a lambda expression of various types and eliminate the need to
create a type for the handlers.
The prefered way of creating a handler is by using the
json_request_function, it would use auto-boxing to return a json object.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The http server handlers can sometimes need to perform async operation,
specifically, when reading files from the disk. To support async
behavior the handlers handle function will return a future, that will be
propagate back, when the future will be ready it will return the reply
to be sent.
When switching from direct function call to future, there is also a need
to switch from references to pointers.
Note that while the request will be discarded, the reply will be
propagate back via the future to the caller.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
This use the routes and the reqeuest found in the http directory and
move all files but main to the http directory
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The route object is the url dispatcher, it uses it matching rules to
find what handler should handle a request, perform the call and handle
exceptions that hanend during the handling.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
This is a migration of the basic json support taken from the
osv/httpserver.
The routes uses the json object to return errors in a json format.
This also adds json_exception which has a constructor from an exception.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The matcher and match rules are used to define and match a url rule. A
rule define a list of string and parameters.
For example, the rule /api/get/{id}/name
Will be mapped by the list of matcher:
str_match for /api/get
param_match for the {id}
and str_match for name
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The class handler_base is a base class for all handlers. All handlers
should inherit and implement the handle method.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The request object was originally taken from the boost server example
and was modified in the OSv http implementation.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
