Merge branch 'master' into parser_upgrade

docs/guides/app.md

@@ -1,5 +1,5 @@
 A Crow app defines an interface to allow the developer access to all the different parts of the framework, without having to manually deal with each one.<br><br>
-An app allows access to the http server (for handling connections), router (for handling URLs and requests), Middlewares (for extending Crow), amoung many others.<br><br>
+An app allows access to the http server (for handling connections), router (for handling URLs and requests), Middlewares (for extending Crow), among many others.<br><br>
 
 Crow has 2 different app types:
 

docs/guides/auth.md

@@ -65,7 +65,7 @@ return true; //or false if the token is invalid
 The way of verifying the token is largely up to the implementation, and involves either Bearer token decoding and verification, or database access, neither of which is in this tutorial's scope.<br><br>
 
 ### Refresh Tokens
-Some services may choose to provide a refresh token alongside the access token. this token can be used to request a new access token if the existing one has expired. It provides convenience and security in that it makes it possible to acquire new access tokens without the need to expose a password. The downside however is that it can allow a malicious entity to keep its access to a compromised account. As such refresh tokens need to be handled with care, kept secure, and always invalidated as soon as a client logs out or requests a new access token.
+Some services may choose to provide a refresh token alongside the access token. This token can be used to request a new access token if the existing one has expired. It provides convenience and security in that it makes it possible to acquire new access tokens without the need to expose a password. The downside however is that it can allow a malicious entity to keep its access to a compromised account. As such refresh tokens need to be handled with care, kept secure, and always invalidated as soon as a client logs out or requests a new access token.
 
 ## Sessions
 While Crow does not provide built in support for user sessions, a community member was kind enough to provide their own implementation on one of the related issue, their comment along with the code is available [here](https://github.com/CrowCpp/Crow/issues/144#issuecomment-860384771) (Please keep in mind that while we appreciate all efforts to push Crow forward, we cannot provide support for this implementation unless it becomes part of the core project).

docs/guides/blueprints.md

@@ -14,7 +14,7 @@ Blueprints let you do the following:<br><br>
 You can define routes in a blueprint, similarly to how `#!cpp CROW_ROUTE(app, "/xyz")` works, you can use `#!cpp CROW_BP_ROUTE(blueprint, "/xyz")` to define a blueprint route.
 
 ### Define a Prefix
-Blueprints can have a prefix assigned to them. This can be done when creating a new blueprint as in `#!cpp crow::blueprint bp("prefix");`. This prefix will be applied to all routes belonging to the blueprint. truning a route such as `/crow/rocks` into `/prefix/crow/rocks`.
+Blueprints can have a prefix assigned to them. This can be done when creating a new blueprint as in `#!cpp crow::blueprint bp("prefix");`. This prefix will be applied to all routes belonging to the blueprint, turning a route such as `/crow/rocks` into `/prefix/crow/rocks`.
 
 !!!Warning
 
@@ -37,7 +37,7 @@ Similar to static directories, You can set a custom templates directory (relativ
     If you want to define a custom templates directory without defining a custom static directory, you can pass the static directory as an empty string. Making your constructor `#!cpp crow::blueprint bp("prefix", "", "custom_templates");`.
 
 ### Define a custom Catchall route
-You can define a custom catchall route for a blueprint by calling `#!cpp CROW_BP_CATCHALL_ROUTE(blueprint)`. This causes any requests with a URL starting with `/prefix` and no route found to call the blueprint's catchall route. if no catchall route is defined, Crow will default to either the parent blueprint or the app's catchall route.
+You can define a custom catchall route for a blueprint by calling `#!cpp CROW_BP_CATCHALL_ROUTE(blueprint)`. This causes any requests with a URL starting with `/prefix` and no route found to call the blueprint's catchall route. If no catchall route is defined, Crow will default to either the parent blueprint or the app's catchall route.
 
 ### Register other Blueprints
 Blueprints can also register other blueprints. This is done through `#!cpp blueprint.register_blueprint(blueprint_2);`. The child blueprint's routes become `/prefix/prefix_2/abc/xyz`.

docs/guides/compression.md

@@ -11,9 +11,9 @@ HTTP compression is by default disabled in crow. Do the following to enable it:
 
     3<sup>rd</sup> point is not needed for MSVC or CMake projects using `Crow::Crow` since `vcpckg.json` and Crow's target already include zlib as a dependency.
 
-For the compression algorim you can use `crow::compression::algorithm::DEFLATE` or `crow::compression::algorithm::GZIP`.<br>
+For the compression algorithm you can use `crow::compression::algorithm::DEFLATE` or `crow::compression::algorithm::GZIP`.<br>
 And now your HTTP responses will be compressed.
 
 ## Websocket Compression
 Crow currently does not support Websocket compression.<br>
-Feel free to discuss the subject with us on Github if you're feeling adventurous and want to try to implement it. We appreciate all the help.
+Feel free to discuss the subject with us on GitHub if you're feeling adventurous and want to try to implement it. We appreciate all the help.

docs/guides/multipart.md

@@ -16,7 +16,7 @@ The structure of a multipart request is typically consistent of:<br>
 Crow supports multipart requests and responses though `crow::multipart::message`.<br>
 A message can be created either by defining the headers, boundary, and individual parts and using them to create the message. or simply by reading a `crow::request`.<br><br>
 
-Once a multipart message has been made, the individual parts can be accessed throught `mpmes.parts`, `parts` is an `std::vector`, so accessing the individual parts should be straightforward.<br>
+Once a multipart message has been made, the individual parts can be accessed throughout `mpmes.parts`, `parts` is an `std::vector`, so accessing the individual parts should be straightforward.<br>
 In order to access the individual part's name or filename, something like `#!cpp mpmes.parts[0].headers[0].params["name"]` sould do the trick.<br><br>
 
 For more info on Multipart messages, go [here](../../reference/namespacecrow_1_1multipart.html)

docs/guides/routes.md

@@ -10,7 +10,7 @@ Which relative path is assigned to the route.<br>
 Using `/hello` means the client will need to access `http://example.com/hello` in order to access the route.<br>
 A path can have parameters, for example `/hello/<int>` will allow a client to input an int into the url which will be in the handler (something like `http://example.com/hello/42`).<br>
 Parameters can be `<int>`, `<uint>`, `<double>`, `<string>`, or `<path>`.<br>
-It's worth nothing that the parameters also need to be defined in the handler, an example of using parameters would be to add 2 numbers based on input:
+It's worth noting that the parameters also need to be defined in the handler, an example of using parameters would be to add 2 numbers based on input:
 ```cpp 
 CROW_ROUTE(app, "/add/<int>/<int>")
 ([](int a, int b)
@@ -48,7 +48,7 @@ For more information on `crow::response` go [here](../../reference/structcrow_1_
 
 ### Return statement
 A `crow::response` is very strictly tied to a route. If you can have something in a response constructor, you can return it in a handler.<br><br>
-The main return type is `std::string`. although you could also return a `crow::json::wvalue` or `crow::multipart::message` directly.<br><br>
+The main return type is `std::string`, although you could also return a `crow::json::wvalue` or `crow::multipart::message` directly.<br><br>
 For more information on the specific constructors for a `crow::response` go [here](../../reference/structcrow_1_1response.html).
 
 ## Returning custom classes
@@ -56,16 +56,16 @@ For more information on the specific constructors for a `crow::response` go [her
 If you have your own class you want to return (without converting it to string and returning that), you can use the `crow::returnable` class.<br>
 to use the returnable class, you only need your class to publicly extend `crow::returnable`, add a `dump()` method that returns your class as an `std::string`, and add a constructor that has a `Content-Type` header as a string argument.<br><br>
 
-your class should look like the following:
+Your class should look like the following:
 ```cpp
 class a : public crow::returnable 
 {
     a() : returnable("text/plain"){};
-
+    
     ...
     ...
     ...
-
+    
     std::string dump() override
     {
         return this.as_string();
@@ -77,7 +77,7 @@ class a : public crow::returnable
 ## Response codes
 **Introduced in: `master`**<br><br>
 
-instead of assigning a response code, you can use the `crow::status` enum, for example you can replace `crow::response(200)` with `crow::response(crow::status::OK)`
+Instead of assigning a response code, you can use the `crow::status` enum, for example you can replace `crow::response(200)` with `crow::response(crow::status::OK)`
 
 ## Catchall routes
 **Introduced in: `v0.3`**<br><br>
@@ -85,4 +85,3 @@ By default, any request that Crow can't find a route for will return a simple 40
 !!!note
 
     For versions higher than 0.3 (excluding patches), Catchall routes handle 404 and 405 responses. The default response will contain the code 404 or 405.
-

docs/guides/testing.md

@@ -1,7 +1,7 @@
 Unit tests can be written in 2 ways for a Crow application.<br><br>
 
 ## The handler method
-Crow Allows users to handle requests that may not come from the network. This is done by calling the `handle(req, res)` method and providing a request and response objects. Which causes crow to identify and run the appropriate handler, returning the resulting response.
+Crow allows users to handle requests that may not come from the network. This is done by calling the `handle(req, res)` method and providing a request and response objects. Which causes crow to identify and run the appropriate handler, returning the resulting response.
 
 ```cpp linenums="1"
   CROW_ROUTE(app, "/place")
@@ -74,4 +74,4 @@ Finally check the result against the expected one.
 
 !!! warning
 
-    Be absolutely sure that the line `app.stop()` runs, whether the test fails or succeedes. Not running it WILL CAUSE OTHER TESTS TO FAIL AND THE TEST TO HANG UNTIL THE PROCESS IS TERMINATED.
+    Be absolutely sure that the line `app.stop()` runs, whether the test fails or succeeds. Not running it WILL CAUSE OTHER TESTS TO FAIL AND THE TEST TO HANG UNTIL THE PROCESS IS TERMINATED.

include/crow/app.h

@@ -280,6 +280,11 @@ namespace crow
             {
                 ssl_server_ = std::move(std::unique_ptr<ssl_server_t>(new ssl_server_t(this, bindaddr_, port_, server_name_, &middlewares_, concurrency_, timeout_, &ssl_context_)));
                 ssl_server_->set_tick_function(tick_interval_, tick_function_);
+                ssl_server_->signal_clear();
+                for (auto snum : signals_)
+                {
+                    ssl_server_->signal_add(snum);
+                }
                 notify_server_start();
                 ssl_server_->run();
             }

include/crow/http_server.h

@@ -28,7 +28,7 @@ namespace crow
     public:
         Server(Handler* handler, std::string bindaddr, uint16_t port, std::string server_name = std::string("Crow/") + VERSION, std::tuple<Middlewares...>* middlewares = nullptr, uint16_t concurrency = 1, uint8_t timeout = 5, typename Adaptor::context* adaptor_ctx = nullptr):
           acceptor_(io_service_, tcp::endpoint(boost::asio::ip::address::from_string(bindaddr), port)),
-          signals_(io_service_, SIGINT, SIGTERM),
+          signals_(io_service_),
           tick_timer_(io_service_),
           handler_(handler),
           concurrency_(concurrency == 0 ? 1 : concurrency),