chore(docs): minor typo fixes (#502)

Author: pranavkonde

README.md

@@ -185,7 +185,7 @@ The lassie library can then be imported into a project with the following import
 import "github.com/filecoin-project/lassie/pkg/lassie"
 ```
 
-The following code shows a small example for how to use the lassie library to fetch a CID:
+The following code shows a small example of how to use the lassie library to fetch a CID:
 
 ```go
 package main
@@ -282,9 +282,9 @@ The `Fetch` function takes a `context.Context`, a `*types.Request`, and a `*type
 
 ### Roots, pieces and payloads
 
-Lassie uses the term **Root** to refer to the head block of a potential graph (DAG) of IPLD blocks. This is typically the block you request, using its CID, when you perform a _fetch_ with Lassie. Of course a root could also be a sub-root of a larger graph, but when performing a retrieval with Lassie, you are focusing on the graph underneath the block you are fetching, and considerations of larger DAGs are not relevant.
+Lassie uses the term **Root** to refer to the head block of a potential graph (DAG) of IPLD blocks. This is typically the block you request, using its CID, when you perform a _fetch_ with Lassie. Of course, a root could also be a sub-root of a larger graph, but when performing a retrieval with Lassie, you are focusing on the graph underneath the block you are fetching, and considerations of larger DAGs are not relevant.
 
-In the Filecoin ecosystem, there exists terminology related to "pieces" and "payloads" and there may be confusion between the way lassie uses the term "root CID" and some of the language used in Filecoin. A **Piece** is a Filecoin storage deal unit, typically containing user data organized into a CAR; then padded to size to form a portion of a Filecoin sector. Filecoin pieces have their own CIDs, and it is possible to retrieve a whole, raw piece, from Filecoin. This can lead to terminology such as "piece root CID". Lassie currently does not perform whole-piece retrievals, and is not intended to be able to handle piece CIDs. Additionally, in Filecoin the term **Payload** is sometimes used in reference to the IPLD data inside a piece when performing a storage or retrieval deal. This is closer to the way Lassie uses the term **Root** and historical Lassie code contains some references to "payloads" that are actually referring to the root CID of a graph.
+In the Filecoin ecosystem, there exists terminology related to "pieces" and "payloads" and there may be confusion between the way lassie uses the term "root CID" and some of the language used in Filecoin. A **Piece** is a Filecoin storage deal unit, typically containing user data organized into a CAR; then padded to size to form a portion of a Filecoin sector. Filecoin pieces have their own CIDs, and it is possible to retrieve a whole, raw piece, from Filecoin. This can lead to terminology such as "piece root CID". Lassie currently does not perform whole-piece retrievals and is not intended to be able to handle piece CIDs. Additionally, in Filecoin the term **Payload** is sometimes used in reference to the IPLD data inside a piece when performing a storage or retrieval deal. This is closer to the way Lassie uses the term **Root** and historical Lassie code contains some references to "payloads" that are actually referring to the root CID of a graph.
 
 ## Contribute
 

docs/CAR.md

@@ -58,7 +58,7 @@ Identity CIDs will not be present as separate blocks within a CAR returned by La
 
 All traversals will include the content at the termination of the `path` specifier, as well as all blocks from the root CID to the `path` terminus where a `path` is provided. At the termination of a provided `path`, or from the root CID where no `path` is provided, the depth of the DAG returned may vary depending on the request or available data.
 
-A "shallow" (e.g. when using `depthType=shallow` with the (HTTP)[HTTP_SPEC.md] server) traversal will include the entire UnixFS entity if the content is found to be UnixFS data. i.e. if the terminus is a sharded UnixFS file, or a sharded UnixFS directory, the blocks required to reconsititute the entire file, or directory will be included. If the termination is a UnixFS sharded directory, only the full directory will be included, not the full DAG of the directory's contents.
+A "shallow" (e.g. when using `depthType=shallow` with the (HTTP)[HTTP_SPEC.md] server) traversal will include the entire UnixFS entity if the content is found to be UnixFS data. i.e. if the terminus is a sharded UnixFS file, or a sharded UnixFS directory, the blocks required to reconstitute the entire file, or directory will be included. If the termination is a UnixFS sharded directory, only the full directory will be included, not the full DAG of the directory's contents.
 
 A "full" (e.g. when using `depthType=full` with the (HTTP)[HTTP_SPEC.md] server) traversal will include the entire DAG from the termination of a `path`, or from the root CID where no `path` is provided.
 

docs/HTTP_SPEC.md

@@ -178,9 +178,9 @@ _OPTIONAL_. `dag-scope=<block|entity|all>`. Defaults to `all`.
 
 Describes the shape of the DAG fetched at the terminus of the specified path whose blocks are included in the returned CAR file after the blocks required to traverse path segments. Unspecified values will respond with a 400 status code.
 
-- `block`: Only the root block at the end of the path is returned after blocks required to verify the specified path segments.
+- `block`: Only the root block at the end of the path is returned after blocks are required to verify the specified path segments.
 
-- `entity`: Returns only the content at the termination of the `{cid}[/path]` specifier, as well as all blocks from the `cid` to the `path` terminus where a `path` is provided. If the content is found to be UnixFS data, the entire UnixFS entity will be included. i.e. if `{cid}[/path]` terminates at a sharded UnixFS file, the blocks required to reconsititute the entire file will be included. If the termination is a UnixFS sharded directory, only the full directory structure itself will be included, not the full DAG of the directory's contents.
+- `entity`: Returns only the content at the termination of the `{cid}[/path]` specifier, as well as all blocks from the `cid` to the `path` terminus where a `path` is provided. If the content is found to be UnixFS data, the entire UnixFS entity will be included. i.e. if `{cid}[/path]` terminates at a sharded UnixFS file, the blocks required to reconstitute the entire file will be included. If the termination is a UnixFS sharded directory, only the full directory structure itself will be included, not the full DAG of the directory's contents.
 
 - `all`: Transmit the entire contiguous DAG that begins at the end of the path query, after blocks required to verify path segments.