Fix a few typos

README.md

@@ -150,7 +150,7 @@ curl --location 'http://localhost:3030/hello.HelloWorldService/SayHello' \
 From here you can stand up a `connect-web` TypeScript/Go project to call your
 API with end-to-end typed RPCs.
 
-## Request/Response Parts
+# Request/Response Parts 🙍‍♂️
 
 Both the request and response types are derived in `axum-connect`. This might
 seem redundant at first.
@@ -159,7 +159,7 @@ Let's go over the easier one first, `RpcIntoResponse`. Connect RPCs are not
 arbitrary HTML requests, they cannot return arbitrary HTML responses. For
 example, streaming responses MUST return an HTTP 200 regardless of error state.
 Keeping with Axum's (fantastic) paradigm, that is enforced by the type system.
-RPC handler may not return arbitrary HTML, but instead must return something
+RPC handlers may not return arbitrary HTML, but instead must return something
 that `axum-connect` knows how to turn into a valid Connect response.
 
 Somewhat less intuitively, `axum-connect` derives `RpcFromRequestParts`, which
@@ -169,14 +169,14 @@ is a problem for the same reason.
 
 Axum also allows a `FromRequest` to occupy the last parameter in a handler which
 consumed the remainder of the HTTP request (including the body). `axum-connect`
-needs to handle the response input itself, so there is no equivalent for RPCs
+needs to handle the request input itself, so there is no equivalent for RPCs
 handlers.
 
 # Roadmap / Stated Non-Goals 🛣️
 
-- Explore better typing that `RpcFromRequestParts`
+- Explore better typing than `RpcFromRequestParts`
   - Ideally clients only need to provide an `RpcIntoError`, but I haven't fully
-    thought this problem though. I just know that having to specific both a
+    thought this problem through. I just know that having to specific both a
     `FromRequestParts` and an `RpcFromRequestParts` on custom types is a PITA.
 - Rework error responses to allow for multiple errors
 - Version checking between generated and runtime code