fix grammar in docs

README.md

@@ -90,7 +90,7 @@ SOAPAction: "http://www.w3.org/2003/05/soap-envelope"
 HTTP/1.1 200
 ```
 
-Hurl can also be used to test HTTP endpoints performances:
+Hurl can also be used to performance test HTTP endpoints:
 
 ```hurl
 GET https://example.org/api/v1/pets
@@ -100,7 +100,7 @@ HTTP/1.0 200
 duration < 1000  # Duration in ms
 ```
 
-And responses bytes content
+And response bytes
 
 ```hurl
 GET https://example.org/data.tar.gz
@@ -122,8 +122,8 @@ sha256 == hex,039058c6f2c0cb492c533b0a4d14ef77cc0f78abccced5287d84a1a2011cfb81;
 # Powered by curl
 
 Hurl is a lightweight binary written in [Rust]. Under the hood, Hurl HTTP engine is
-powered by [libcurl], one of the most powerful and reliable file transfer library.
-With its text file format, Hurl adds syntactic sugar to run and tests HTTP requests,
+powered by [libcurl], one of the most powerful and reliable file transfer libraries.
+With its text file format, Hurl adds syntactic sugar to run and test HTTP requests,
 but it's still the [curl] that we love.
 
 # Feedbacks
@@ -293,7 +293,7 @@ Authorization: Basic Ym9iOnNlY3JldA==
 ```
 
 Basic authentication allows per request authentication.
-If you want to add basic authentication to all the request of a Hurl file
+If you want to add basic authentication to all the requests of a Hurl file
 you could use [`-u/--user` option].
 
 ## Sending Data
@@ -705,7 +705,7 @@ More information on asserts can be found here [https://hurl.dev/docs/asserting-r
 
 ## Options
 
-Options that exist in curl have exactly the same semantic. 
+Options that exist in curl have exactly the same semantics.
 
 Options specified on the command line are defined for every Hurl file's entry.
 

docs/asserting-response.md

@@ -287,7 +287,7 @@ cookie "LSID[SameSite]" equals "Lax"
 ```
 
 > `Secure` and `HttpOnly` attributes can only be tested with `exists` or `not exists` predicates
-> to reflect the [Set-Cookie header] semantic (in other words, queries `<cookie-name>[HttpOnly]`
+> to reflect the [Set-Cookie header] semantics (in other words, queries `<cookie-name>[HttpOnly]`
 > and `<cookie-name>[Secure]` don't return boolean).
 
 ### Body assert

docs/capturing-response.md

@@ -3,11 +3,11 @@
 ## Captures
 
 Captures are optional values captured from the HTTP response, in a named variable. Captures can be the
-response status code, part or the entire of the body, and response headers.
+response status code, part of or the entire the body, and response headers.
 
 Captured variables are available through a run session; each new value of a given variable overrides the last value.
 
-Captures allow using data from one request to another request, when working with
+Captures allow using data from one request in another request, when working with
 [CSRF tokens] for instance. Variables can also be initialized at the start of the
 session, by passing [variable values], or can be used in [templates].
 
@@ -169,7 +169,7 @@ HTTP/1.1 200
 ```
 
 XPath captures are not limited to node values (like string, or boolean); any
-valid XPath can be captured and assert with variable asserts.
+valid XPath can be captured and asserted with variable asserts.
 
 ```hurl
 # Test that the XML endpoint return 200 pets

docs/entry.md

@@ -2,7 +2,7 @@
 
 ## Definition
 
-A Hurl file is a list of entry, each entry being a mandatory [request], optionally followed by a [response].
+A Hurl file is a list of entries, each entry being a mandatory [request], optionally followed by a [response].
 
 Responses are not mandatory, a Hurl file consisting only of requests is perfectly valid. To sum up, responses can be used
 to [capture values] to perform subsequent requests, or [add asserts to HTTP responses].

docs/home.md

@@ -88,7 +88,7 @@ SOAPAction: "http://www.w3.org/2003/05/soap-envelope"
 HTTP/1.1 200
 ```
 
-Hurl can also be used to test HTTP endpoints performances:
+Hurl can also be used to performance test HTTP endpoints:
 
 ```hurl
 GET https://example.org/api/v1/pets
@@ -98,7 +98,7 @@ HTTP/1.0 200
 duration < 1000  # Duration in ms
 ```
 
-And responses bytes content
+And response bytes
 
 ```hurl
 GET https://example.org/data.tar.gz
@@ -120,8 +120,8 @@ sha256 == hex,039058c6f2c0cb492c533b0a4d14ef77cc0f78abccced5287d84a1a2011cfb81;
 # Powered by curl
 
 Hurl is a lightweight binary written in [Rust]. Under the hood, Hurl HTTP engine is
-powered by [libcurl], one of the most powerful and reliable file transfer library.
-With its text file format, Hurl adds syntactic sugar to run and tests HTTP requests,
+powered by [libcurl], one of the most powerful and reliable file transfer libraries.
+With its text file format, Hurl adds syntactic sugar to run and test HTTP requests,
 but it's still the [curl] that we love.
 
 # Feedbacks

docs/hurl-file.md

@@ -45,7 +45,7 @@ jsonpath "$.slideshow.title" == "A beautiful ✈!"
 jsonpath "$.slideshow.title" == "A beautiful \u{2708}!"
 ```
 
-In some case, (in headers value, etc..), you will also need to escape # to distinguish from a comment.
+In some case, (in headers value, etc..), you will also need to escape # to distinguish it from a comment.
 In the following example:
 
 ```hurl

docs/manual.md

@@ -121,7 +121,7 @@ More information on asserts can be found here [https://hurl.dev/docs/asserting-r
 
 ## Options
 
-Options that exist in curl have exactly the same semantic. 
+Options that exist in curl have exactly the same semantics.
 
 Options specified on the command line are defined for every Hurl file's entry.
 

docs/manual/hurl.1

@@ -1,4 +1,4 @@
-.TH hurl 1 "25 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
+.TH hurl 1 "28 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
 .SH NAME
 
 hurl - run and test HTTP requests.
@@ -104,7 +104,7 @@ More information on asserts can be found here \fIhttps://hurl.dev/docs/asserting
 
 .SH OPTIONS
 
-Options that exist in curl have exactly the same semantic. 
+Options that exist in curl have exactly the same semantics.
 
 Options specified on the command line are defined for every Hurl file's entry.
 

docs/manual/hurl.md

@@ -119,7 +119,7 @@ More information on asserts can be found here [https://hurl.dev/docs/asserting-r
 
 ## OPTIONS
 
-Options that exist in curl have exactly the same semantic. 
+Options that exist in curl have exactly the same semantics.
 
 Options specified on the command line are defined for every Hurl file's entry.
 

docs/manual/hurlfmt.1

@@ -1,4 +1,4 @@
-.TH hurl 1 "25 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
+.TH hurl 1 "28 Sep 2022" "hurl 1.8.0-SNAPSHOT" " Hurl Manual"
 .SH NAME
 
 hurlfmt - format Hurl files
@@ -13,7 +13,7 @@ hurlfmt - format Hurl files
 .SH DESCRIPTION
 
 .B hurlfmt
-formats Hurl files and converts to other formats.
+formats Hurl files and converts them to other formats.
 
 With no FILE, read standard input.
 

docs/manual/hurlfmt.md

@@ -10,7 +10,7 @@ hurlfmt - format Hurl files
 
 ## DESCRIPTION
 
-**hurlfmt** formats Hurl files and converts to other formats.
+**hurlfmt** formats Hurl files and converts them to other formats.
 
 With no FILE, read standard input.
 

docs/request.md

@@ -333,7 +333,7 @@ Authorization: Basic Ym9iOnNlY3JldA==
 ```
 
 Basic authentication allows per request authentication.
-If you want to add basic authentication to all the request of a Hurl file
+If you want to add basic authentication to all the requests of a Hurl file
 you can use [`-u/--user` option].
 
 ### Body

docs/response.md

@@ -3,7 +3,7 @@
 ## Definition
 
 Responses can be used to capture values to perform subsequent requests, or add asserts to HTTP responses. Response on
-requests are optional, a Hurl file can only be a sequence of [requests].
+requests are optional, a Hurl file can just consist of a sequence of [requests].
 
 A response describes the expected HTTP response, with mandatory [version and status], followed by optional [headers],
 [captures], [asserts] and [body]. Assertions in the expected HTTP response describe values of the received HTTP response.

docs/running-tests.md

@@ -84,7 +84,7 @@ To use variables in your tests, you can:
 - use [`--variables-file` option]
 - define environment variables, for instance `HURL_foo=bar`
 
-You will find a detail description in the [Injecting Variables] section of the doc.
+You will find a detailed description in the [Injecting Variables] section of the docs.
 
 [`--output /dev/null`]: /docs/manual.md#output
 [`--test`]: /docs/manual.md#test
@@ -93,4 +93,4 @@ You will find a detail description in the [Injecting Variables] section of the d
 [`--glob` option]: /docs/manual.md#glob
 [`--variable` option]: /docs/manual.md#variable
 [`--variables-file` option]: /docs/manual.md#variables-file
-[Injecting Variables]: /docs/templates.md#injecting-variables
+[Injecting Variables]: /docs/templates.md#injecting-variables

docs/samples.md

@@ -82,7 +82,7 @@ Authorization: Basic Ym9iOnNlY3JldA==
 ```
 
 Basic authentication allows per request authentication.
-If you want to add basic authentication to all the request of a Hurl file
+If you want to add basic authentication to all the requests of a Hurl file
 you could use [`-u/--user` option].
 
 ## Sending Data
@@ -383,4 +383,4 @@ bytes startsWith hex,efbbbf;
 [`-u/--user` option]: /docs/manual.md#user
 [curl]: https://curl.se
 [entry]: /docs/entry.md
-[`--test` option]: /docs/manual.md#test
+[`--test` option]: /docs/manual.md#test

docs/templates.md

@@ -19,7 +19,7 @@ X-CSRF-TOKEN: {{csrf_token}}
 HTTP/1.1 302
 ```
 
-In this example, we capture the value of the [CSRF token] from the body a first response, and inject it
+In this example, we capture the value of the [CSRF token] from the body of the first response, and inject it
 as a header in the next POST request.
 
 ```hurl
@@ -39,7 +39,7 @@ In this second example, we capture the body in a variable `index`, and reuse thi
 
 ## Types
 
-Variable are typed, and can be either string, bool, number, `null` or collections. Depending on the variable type,
+Variables are typed, and can be either string, bool, number, `null` or collections. Depending on the variable type,
 templates can be rendered differently. Let's say we have captured an integer value into a variable named
 `count`:
 

docs/tutorial/adding-asserts.md

@@ -187,7 +187,7 @@ header "Content-Type" == "text/html;charset=UTF-8"
 > In this case, the `header` query will return collections and could be tested with
 > `countEqual` or `include` predicates.
 
-For HTTP headers, we can also use an [implicit header assert]. You can use indifferently implicit or
+For HTTP headers, we can also use an [implicit header assert]. You can use either implicit or
 explicit header assert: the implicit one allows you to only check the exact value of the header,
 while the explicit one allows you to use other [predicates] (like `contains`, `startsWith`, `matches` etc...).
 
@@ -242,7 +242,7 @@ it simplifies tests on cookies, particularly when there are multiple `Set-Cookie
 > has no Javascript runtime and stays close to the HTTP layer. With others tools relying on headless browser, it can be
 > difficult to access some HTTP requests attributes, like `Set-Cookie` header.
 
-So to test that our server is responding a `HttpOnly` session cookie, we can modify our file and add cookie asserts.
+So to test that our server is responding with a `HttpOnly` session cookie, we can modify our file and add cookie asserts.
 
 4. Add two cookie asserts on the cookie `JESSIONID`:
 

docs/tutorial/captures.md

@@ -1,12 +1,12 @@
 # Captures
 
 We have seen how to chain requests in a Hurl file. In some use cases, you want
-to use data from one request and inject it in another one. That what captures
+to use data from one request and inject it in another one. That's what captures
 are all about.
 
 ## Capturing a CSRF Token
 
-In our quiz application, user can create a quiz at <http://localhost:8080/new-quiz>.
+In our quiz application, a user can create a quiz at <http://localhost:8080/new-quiz>.
 The HTML page is a [form] where the user can input:
 
 - a required name
@@ -40,7 +40,7 @@ page of the new quiz, indicating creation success.
 
 Let's try to test it!
 
-Form values can be sent using a [Form parameters section], with each key followed by it
+Form values can be sent using a [Form parameters section], with each key followed by its
 corresponding value.
 
 1. Create a new file named `create-quiz.hurl`:
@@ -59,7 +59,7 @@ HTTP/1.1 302
 ```
 
 > When sending form data with a Form parameters section, you don't need to set the
-> `Content-Type` HTTP header: Hurl enfers that the content type of the request is `application/x-www-form-urlencoded`.
+> `Content-Type` HTTP header: Hurl infers that the content type of the request is `application/x-www-form-urlencoded`.
 
 2. Run `create-quiz.hurl`:
 
@@ -239,7 +239,7 @@ detail_url: header "Location"
 header "Location" matches "/quiz/detail/[a-f0-9]{8}"
 ```
 
-3. Add a request to get the detail page where the user has been redirected:
+3. Add a request to get the detail page that the user has been redirected to:
 
 ```hurl
 # First, get the quiz creation page to capture
@@ -307,7 +307,7 @@ HTTP/1.1 200
 ```
 
 We have seen how to [capture response data] in a variable and use it in others request.
-Captures and asserts share the sames queries, and can be inter-mixed in the same response.
+Captures and asserts share the same queries, and can be inter-mixed in the same response.
 Finally, Hurl doesn't follow redirect by default, but captures can be used to run each step
 of a redirection.
 

docs/tutorial/chaining-requests.md

@@ -22,7 +22,7 @@ cookie "JSESSIONID[HttpOnly]" exists
 ```
 
 We're only running one HTTP request and have already added lots of tests on the response. Don't hesitate to add
-many tests, the more asserts you will write, the less fragile will be your tests suite.
+many tests, the more asserts you write, the less fragile your tests suite will become.
 
 Now, we want to perform other HTTP requests and keep adding tests. In the same file, we can simply write another
 request following our first request. Let's say we want to test that we have a [404 page] on a broken link:
@@ -57,7 +57,7 @@ xpath "string(//h1)" == "Error 404, Page not Found!"
 Now, we have two entries in our Hurl file: each entry is composed of one request and one expected response
 description.
 
-> In a Hurl file, response description are optional. We could also have written
+> In a Hurl file, response descriptions are optional. We could also have written
 > our file with only requests:
 >
 > ```hurl
@@ -80,7 +80,7 @@ Failed files:    0 (0.0%)
 Duration:        12 ms
 ```
 
-We can see that the test is still ok, now two requests are ran in chain, and each response can be
+We can see that the test is still ok, now two requests are being run in sequence, and each response can be
 tested independently.
 
 ## Test REST Api
@@ -112,7 +112,7 @@ So, our health api returns this JSON resource:
 ```
 
 We can test it with a [JsonPath assert]. JsonPath asserts have the same structure as XPath asserts: a query
-followed by a predicate. [JsonPath query] are simple expressions to inspect a JSON object.
+followed by a predicate. A [JsonPath query] is a simple expression to inspect a JSON object.
 
 2. Modify `basic.hurl` to add a third request that asserts our </api/health> REST api:
 
@@ -134,10 +134,10 @@ jsonpath "$.healthy" == true
 jsonpath "$.operationId" exists
 ```
 
-Like XPath assert, JsonPath predicates values are typed. String, boolean, number and
-collections are supported. Let's practice it by using another api. In our Quiz model, a
+Like XPath assert, JsonPath predicate values are typed. String, boolean, number and
+collections are supported. Let's practice writing JsonPath asserts by using another api. In our Quiz model, a
 quiz is a set of questions, and a question resource is exposed through a
-REST api exposed et <http://localhost:8080/api/questions>. We can use it to add checks on getting questions
+REST api exposed at <http://localhost:8080/api/questions>. We can use it to add checks on getting questions
 through the api endpoint.
 
 3. Add JSONPath asserts on the </api/questions> REST apis:
@@ -167,7 +167,7 @@ jsonpath "$[0].title" == "What is a pennyroyal?"
 > in our Quiz application. That's something you don't want to do when building
 > your application, you want to build an app production ready. A better way to
 > do this should have been to expose a "debug" or "integration" mode on our app
-> positioned by environment variables. If our app is launched in "integration" mode,
+> defined by environment variables. If our app is launched in "integration" mode,
 > mocked data is used and asserts can be tested on known values. Our app could also use
 > a mocked database, configured in our tests suits.