Merge branch 'develop' of https://github.com/geffzhang/Ocelot into develop

docs/features/configuration.rst

@@ -88,7 +88,7 @@ to you
                         .AddEnvironmentVariables();
                 })
 
-Ocelot will now use the environment specific configuration and fall back to ocelot.json if there isnt one.
+Ocelot will now use the environment specific configuration and fall back to ocelot.json if there isn't one.
 
 You also need to set the corresponding environment variable which is ASPNETCORE_ENVIRONMENT. More info on this can be found in the `asp.net core docs <https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments>`_.
 
@@ -131,7 +131,7 @@ You can also give Ocelot a specific path to look in for the configuration files
                 .AddEnvironmentVariables();
         })
 
-Ocelot needs the HostingEnvironment so it know's to exclude anything environment specific from the algorithm. 
+Ocelot needs the HostingEnvironment so it knows to exclude anything environment specific from the algorithm. 
 
 Store configuration in consul
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -161,7 +161,7 @@ finds your Consul agent and interacts to load and store the configuration from C
         }
     }
 
-I decided to create this feature after working on the raft consensus algorithm and finding out its super hard. Why not take advantage of the fact Consul already gives you this! 
+I decided to create this feature after working on the Raft consensus algorithm and finding out its super hard. Why not take advantage of the fact Consul already gives you this! 
 I guess it means if you want to use Ocelot to its fullest you take on Consul as a dependency for now.
 
 This feature has a 3 second ttl cache before making a new request to your local consul agent.
@@ -202,22 +202,23 @@ Use HttpHandlerOptions in ReRoute configuration to set up HttpHandler behavior:
 
 1. AllowAutoRedirect is a value that indicates whether the request should follow redirection responses. Set it true if the request should automatically 
 follow redirection responses from the Downstream resource; otherwise false. The default value is false.
+
 2. UseCookieContainer is a value that indicates whether the handler uses the CookieContainer 
 property to store server cookies and uses these cookies when sending requests. The default value is false. Please note
 that if you are using the CookieContainer Ocelot caches the HttpClient for each downstream service. This means that all requests
 to that DownstreamService will share the same cookies. `Issue 274 <https://github.com/ThreeMammals/Ocelot/issues/274>`_ was created because a user
 noticed that the cookies were being shared. I tried to think of a nice way to handle this but I think it is impossible. If you don't cache the clients
 that means each request gets a new client and therefore a new cookie container. If you clear the cookies from the cached client container you get race conditions due to inflight
-requests. This would also mean that subsequent requests dont use the cookies from the previous response! All in all not a great situation. I would avoid setting 
+requests. This would also mean that subsequent requests don't use the cookies from the previous response! All in all not a great situation. I would avoid setting 
 UseCookieContainer to true unless you have a really really good reason. Just look at your response headers and forward the cookies back with your next request! 
 
 SSL Errors
 ^^^^^^^^^^
 
-Id you want to ignore SSL warnings / errors set the following in your ReRoute config.
+If you want to ignore SSL warnings / errors set the following in your ReRoute config.
 
 .. code-block:: json
 
     "DangerousAcceptAnyServerCertificateValidator": false
 
-I don't reccomend doing this, I suggest creating your own certificate and then getting it trusted by your local / remote machine if you can.
+I don't recommend doing this, I suggest creating your own certificate and then getting it trusted by your local / remote machine if you can.

docs/features/raft.rst

@@ -3,7 +3,7 @@ Raft (EXPERIMENTAL DO NOT USE IN PRODUCTION)
 
 Ocelot has recently integrated `Rafty <https://github.com/ThreeMammals/Rafty>`_ which is an implementation of Raft that I have also been working on over the last year. This project is very experimental so please do not use this feature of Ocelot in production until I think it's OK.
 
-Raft is a distributed concensus algorythm that allows a cluster of servers (Ocelots) to maintain local state without having a centralised database for storing state (e.g. SQL Server). 
+Raft is a distributed concensus algorithm that allows a cluster of servers (Ocelots) to maintain local state without having a centralised database for storing state (e.g. SQL Server). 
 
 To get Raft support you must first install the Ocelot Rafty package.
 

docs/features/requestaggregation.rst

@@ -1,7 +1,7 @@
 Request Aggregation
 ===================
 
-Ocelot allows you to specify Aggregate ReRoutes that compose multiple normal ReRoutes and map their responses into one object. This is usual where you have 
+Ocelot allows you to specify Aggregate ReRoutes that compose multiple normal ReRoutes and map their responses into one object. This is usually where you have 
 a client that is making multiple requests to a server where it could just be one. This feature allows you to start implementing back end for a front end type 
 architecture with Ocelot.
 

docs/features/routing.rst

@@ -189,7 +189,7 @@ this sounds interesting to you.
 Query Strings
 ^^^^^^^^^^^^^
 
-Ocelot allows you to specify a querystring as part of the DownstreamPathTemplate like the example below.
+Ocelot allows you to specify a query string as part of the DownstreamPathTemplate like the example below.
 
 .. code-block:: json
 
@@ -241,5 +241,5 @@ Ocelot will also allow you to put query string parameters in the UpstreamPathTem
         }
     }
 
-In this example Ocelot will only match requests that have a matching url path and the querystring starts with unitId=something. You can have other queries after this
+In this example Ocelot will only match requests that have a matching url path and the query string starts with unitId=something. You can have other queries after this
 but you must start with the matching parameter. Also Ocelot will swap the {unitId} parameter from the query string and use it in the downstream request path. 

docs/features/servicediscovery.rst

@@ -54,7 +54,7 @@ and LeastConnection algorithm you can use. If no load balancer is specified Ocel
 
 When this is set up Ocelot will lookup the downstream host and port from the service discover provider and load balance requests across any available services.
 
-A lot of people have asked me to implement a feature where Ocelot polls consul for latest service information rather than per request. If you want to poll consul for the latest services rather than per request (default behaviour) then you need to set the following configuration.
+A lot of people have asked me to implement a feature where Ocelot polls Consul for latest service information rather than per request. If you want to poll Consul for the latest services rather than per request (default behaviour) then you need to set the following configuration.
 
 .. code-block:: json
 
@@ -67,9 +67,9 @@ A lot of people have asked me to implement a feature where Ocelot polls consul f
 
 The polling interval is in milliseconds and tells Ocelot how often to call Consul for changes in service configuration.
 
-Please note there are tradeoffs here. If you poll Consul it is possible Ocelot will not know if a service is down depending on your polling interval and you might get more errors than if you get the latest services per request. This really depends on how volitile your services are. I doubt it will matter for most people and polling may give a tiny performance improvement over calling consul per request (as sidecar agent). If you are calling a remote consul agent then polling will be a good performance improvement.
+Please note there are tradeoffs here. If you poll Consul it is possible Ocelot will not know if a service is down depending on your polling interval and you might get more errors than if you get the latest services per request. This really depends on how volatile your services are. I doubt it will matter for most people and polling may give a tiny performance improvement over calling Consul per request (as sidecar agent). If you are calling a remote Consul agent then polling will be a good performance improvement.
 
-You services need to be added to Consul something like below (c# style but hopefully this make sense)...The only important thing to note
+Your services need to be added to Consul something like below (C# style but hopefully this make sense)...The only important thing to note
 is not to add http or https to the Address field. I have been contacted before about not accepting scheme in Address and accepting scheme
 in address. After reading `this <https://www.consul.io/docs/agent/services.html>`_ I don't think the scheme should be in there.
 
@@ -108,7 +108,7 @@ If you are using ACL with Consul Ocelot supports adding the X-Consul-Token heade
         "Type": "Consul"
     }
 
-Ocelot will add this token to the consul client that it uses to make requests and that is then used for every request.
+Ocelot will add this token to the Consul client that it uses to make requests and that is then used for every request.
 
 Eureka
 ^^^^^^
@@ -160,8 +160,8 @@ Dynamic Routing
 
 This feature was requested in `issue 340 <https://github.com/ThreeMammals/Ocelot/issue/340>`_. The idea is to enable dynamic routing when using a service discovery provider (see that section of the docs for more info). In this mode Ocelot will use the first segment of the upstream path to lookup the downstream service with the service discovery provider. 
 
-An example of this would be calling ocelot with a url like https://api.mywebsite.com/product/products. Ocelot will take the first segment of 
-the path which is product and use it as a key to look up the service in consul. If consul returns a service Ocelot will request it on whatever host and port comes back from consul plus the remaining path segments in this case products thus making the downstream call http://hostfromconsul:portfromconsul/products. Ocelot will apprend any query string to the downstream url as normal.
+An example of this would be calling Ocelot with a url like https://api.mywebsite.com/product/products. Ocelot will take the first segment of 
+the path which is product and use it as a key to look up the service in Consul. If Consul returns a service Ocelot will request it on whatever host and port comes back from Consul plus the remaining path segments in this case products thus making the downstream call http://hostfromconsul:portfromconsul/products. Ocelot will apprend any query string to the downstream url as normal.
 
 In order to enable dynamic routing you need to have 0 ReRoutes in your config. At the moment you cannot mix dynamic and configuration ReRoutes. In addition to this you need to specify the Service Discovery provider details as outlined above and the downstream http/https scheme as DownstreamScheme.