fix: vale linter issue

Signed-off-by: Achanandhi-M <achanandhi.m@gmail.com>

Author: Achanandhi-M

versioned_docs/version-2.0.0/ci-cd/github.md

@@ -122,8 +122,8 @@ _And... voila! You have successfully integrated keploy in GitHub CI pipeline 
 
 ## GitHub Actions
 
-GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow unde `.github/workflow` with the name `keploy-test.yml`: -
-GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow unde `.github/workflow` with the name `keploy-test.yml`: -
+GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow under `.github/workflow` with the name `keploy-test.yml`: -
+GitHub Actions are a more advanced way to integrate Keploy with GitHub. We will be using [express-mongoose](https://github.com/keploy/samples-typescript/tree/main/express-mongoose) sample-application for the example. Create a new workflow under `.github/workflow` with the name `keploy-test.yml`: -
 
 ```yaml
 jobs:

versioned_docs/version-2.0.0/dependencies/http.md

@@ -39,7 +39,7 @@ The http parser is basically divided into two sections, `encode` and `decode`, t
 
 So in the record mode, the encode function is provided with the initial request, which is written to the destination connection and checked if the request is chunked, if it is then parser keeps reading the request from the client connection and write it to the destination connection.
 
-Next, if the request contains the expect header or not. The expect header is used by a client when sending very large requests. So it is basically used to ask the server if it is ready to accept such a large req or not, if it is, then the server responds with a `"100-continue"` response. This is what we also check by writing the request to the destination connection and reading the respnse from it. We start reading the response and we handle chunking in that case as well. Then finally, keploy parse the request and response to store it in mocks.
+Next, if the request contains the expect header or not. The expect header is used by a client when sending very large requests. So it is basically used to ask the server if it is ready to accept such a large req or not, if it is, then the server responds with a `"100-continue"` response. This is what we also check by writing the request to the destination connection and reading the response  from it. We start reading the response and we handle chunking in that case as well. Then finally, keploy parse the request and response to store it in mocks.
 
 Hope this helps you out, if you still have any questions, reach out to us .
 

versioned_docs/version-2.0.0/quickstart/node-jwt-sql.md

@@ -175,8 +175,8 @@ Our testcases will fail as the token would expire and new Token will generated a
 
 <img src="/docs/img/jwt-test-fail.png" alt="Sample Keploy Test Result Node JWT" width="100%" style={{ borderRadius: '5px' }} />
 
-But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
-But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
+But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
+But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
 
 ```
         noise:
@@ -319,7 +319,7 @@ Our testcases will fail as the token would expire and new Token will generated a
 
 <img src="/docs/img/jwt-test-fail.png" alt="Sample Keploy Test Result Node JWT" width="100%" style={{ borderRadius: '5px' }} />
 
-But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
+But for this application, the Token expiration is 10 mins so let's go ahead and test the application within 10 mins. Let's add the `Etag` and `accessToken` as the noise in the `test-3.yml` on line 45 under `header.Date`. The file would look like:-
 
 ```
         noise:

versioned_docs/version-2.0.0/server/sdk-installation/python.md

@@ -32,7 +32,7 @@ To get the coverage data for your unit tests:
 coverage run --data-file=.coverage.unit test_program.py
 ```
 
-Here, test_program.py is the unit test program you want to run, and --data-file is set to .coverage.unit becuase, by default, raw coverage data would be written to .coverage which is where coverage data for keploy tests is present, so to avoid overwritting we pass a new file through data-file flag.
+Here, test_program.py is the unit test program you want to run, and --data-file is set to .coverage.unit because, by default, raw coverage data would be written to .coverage which is where coverage data for keploy tests is present, so to avoid overwriting we pass a new file through data-file flag.
 
 > Note: If you face any problems with running the coverage library, you can refer to the documentation.