Merge pull request #1734 from biergit/patch-1

Fix typos

consumer/junit5/README.md

@@ -162,15 +162,15 @@ bodies, etc.). This works by using the V3 spec generators with provider state ca
 of where this would be useful is API calls that require an ID which would be auto-generated by the database on the
 provider side, so there is no way to know what the ID would be beforehand.
 
-The following DSL methods all you to set an expression that will be parsed with the values returned from the provider states:
+The following DSL methods allow you to set an expression that will be parsed with the values returned from the provider states:
 
 For JSON bodies, use `valueFromProviderState`.<br/>
 For headers, use `headerFromProviderState`.<br/>
 For query parameters, use `queryParameterFromProviderState`.<br/>
 For paths, use `pathFromProviderState`.
 
 For example, assume that an API call is made to get the details of a user by ID. A provider state can be defined that
-specifies that the user must be exist, but the ID will be created when the user is created. So we can then define an
+specifies that the user must exist, but the ID will be created when the user is created. So we can then define an
 expression for the path where the ID will be replaced with the value returned from the provider state callback.
 
 ```java
@@ -235,7 +235,7 @@ messages and synchronous request/response messages.
 
 ## Asynchronous messages
 
-Asynchronous messages are you normal type of single shot or fire and forget type messages. They are typically sent to a
+Asynchronous messages are your normal type of single shot or fire and forget type messages. They are typically sent to a
 message queue or topic as a notification or event. With Pact tests, we will be testing that our consumer of the messages
 works with the messages setup as the expectations in test. This should be the message handler code that processes the
 actual messages that come off the message queue in production.