Fix common grammar mistakes and add small documentation for AppConfig's Default implementation (#2793)

actix-web/src/app.rs

@@ -60,7 +60,7 @@ where
     /// [`HttpRequest::app_data`](crate::HttpRequest::app_data) method at runtime.
     ///
     /// # [`Data<T>`]
-    /// Any [`Data<T>`] type added here can utilize it's extractor implementation in handlers.
+    /// Any [`Data<T>`] type added here can utilize its extractor implementation in handlers.
     /// Types not wrapped in `Data<T>` cannot use this extractor. See [its docs](Data<T>) for more
     /// about its usage and patterns.
     ///

actix-web/src/app_service.rs

@@ -257,7 +257,7 @@ impl ServiceFactory<ServiceRequest> for AppRoutingFactory {
     type Future = LocalBoxFuture<'static, Result<Self::Service, Self::InitError>>;
 
     fn new_service(&self, _: ()) -> Self::Future {
-        // construct all services factory future with it's resource def and guards.
+        // construct all services factory future with its resource def and guards.
         let factory_fut = join_all(self.services.iter().map(|(path, factory, guards)| {
             let path = path.clone();
             let guards = guards.borrow_mut().take().unwrap_or_default();

actix-web/src/config.rs

@@ -153,6 +153,16 @@ impl AppConfig {
 }
 
 impl Default for AppConfig {
+    /// Returns the default AppConfig.
+    /// Note: The included socket address is "127.0.0.1".
+    ///
+    /// 127.0.0.1: non-routable meta address that denotes an unknown, invalid or non-applicable target.
+    /// If you need a service only accessed by itself, use a loopback address.
+    /// A loopback address for IPv4 is any loopback address that begins with "127".
+    /// Loopback addresses should be only used to test your application locally.
+    /// The default configuration provides a loopback address.
+    ///
+    /// 0.0.0.0: if configured to use this special address, the application will listen to any IP address configured on the machine.
     fn default() -> Self {
         AppConfig::new(
             false,

actix-web/src/guard.rs

@@ -254,7 +254,7 @@ impl Guard for AllGuard {
     }
 }
 
-/// Wraps a guard and inverts the outcome of it's `Guard` implementation.
+/// Wraps a guard and inverts the outcome of its `Guard` implementation.
 ///
 /// # Examples
 /// The handler below will be called for any request method apart from `GET`.
@@ -459,7 +459,7 @@ impl Guard for HostGuard {
                 return scheme == req_host_uri_scheme;
             }
 
-            // TODO: is the the correct behavior?
+            // TODO: is this the correct behavior?
             // falls through if scheme cannot be determined
         }
 

actix-web/src/handler.rs

@@ -37,7 +37,7 @@ use crate::{
 /// Thanks to Rust's type system, Actix Web can infer the function parameter types. During the
 /// extraction step, the parameter types are described as a tuple type, [`from_request`] is run on
 /// that tuple, and the `Handler::call` implementation for that particular function arity
-/// destructures the tuple into it's component types and calls your handler function with them.
+/// destructures the tuple into its component types and calls your handler function with them.
 ///
 /// In pseudo-code the process looks something like this:
 /// ```ignore

actix-web/src/response/response.rs

@@ -343,7 +343,7 @@ mod response_fut_impl {
 
     // Future is only implemented for BoxBody payload type because it's the most useful for making
     // simple handlers without async blocks. Making it generic over all MessageBody types requires a
-    // future impl on Response which would cause it's body field to be, undesirably, Option<B>.
+    // future impl on Response which would cause its body field to be, undesirably, Option<B>.
     //
     // This impl is not particularly efficient due to the Response construction and should probably
     // not be invoked if performance is important. Prefer an async fn/block in such cases.