Remove Ocelot specific Middleware to make Ocelot more compatible with kestrel middleware and get ready for YARP

docs/introduction/bigpicture.rst

@@ -1,23 +1,13 @@
 Big Picture
 ===========
 
-Ocelot is aimed at people using .NET running 
-a micro services / service orientated architecture 
-that need a unified point of entry into their system.
+Ocelot is aimed at people using .NET running a micro services / service orientated architecture that need a unified point of entry into their system.
 
-In particular I want easy integration with 
-IdentityServer reference and bearer tokens. 
+In particular I want easy integration with IdentityServer reference and bearer tokens. 
 
 Ocelot is a bunch of middlewares in a specific order.
 
-Ocelot manipulates the HttpRequest object into a state specified by its configuration until 
-it reaches a request builder middleware where it creates a HttpRequestMessage object which is 
-used to make a request to a downstream service. The middleware that makes the request is 
-the last thing in the Ocelot pipeline. It does not call the next middleware. 
-The response from the downstream service is stored in a per request scoped repository 
-and retrieved as the requests goes back up the Ocelot pipeline. There is a piece of middleware 
-that maps the HttpResponseMessage onto the HttpResponse object and that is returned to the client.
-That is basically it with a bunch of other features.
+Ocelot manipulates the HttpRequest object into a state specified by its configuration until it reaches a request builder middleware where it creates a HttpRequestMessage object which is used to make a request to a downstream service. The middleware that makes the request is the last thing in the Ocelot pipeline. It does not call the next middleware. There is a piece of middleware that maps the HttpResponseMessage onto the HttpResponse object and that is returned to the client. That is basically it with a bunch of other features.
 
 The following are configurations that you use when deploying Ocelot.
 

docs/introduction/contributing.rst

@@ -1,5 +1,4 @@
 Contributing
 ============
 
-Pull requests, issues and commentary welcome! No special process just create a request and get in 
-touch either via gitter or create an issue. 
+Pull requests, issues and commentary welcome! No special process just create a request and get in touch either via gitter or create an issue. 

docs/introduction/gettingstarted.rst

@@ -52,16 +52,13 @@ If you want some example that actually does something use the following:
         }
     }
 
-The most important thing to note here is BaseUrl. Ocelot needs to know the URL it is running under
-in order to do Header find & replace and for certain administration configurations. When setting this URL it should be the external URL that clients will see Ocelot running on e.g. If you are running containers Ocelot might run on the url http://123.12.1.1:6543 but has something like nginx in front of it responding on https://api.mybusiness.com. In this case the Ocelot base url should be https://api.mybusiness.com. 
+The most important thing to note here is BaseUrl. Ocelot needs to know the URL it is running under in order to do Header find & replace and for certain administration configurations. When setting this URL it should be the external URL that clients will see Ocelot running on e.g. If you are running containers Ocelot might run on the url http://123.12.1.1:6543 but has something like nginx in front of it responding on https://api.mybusiness.com. In this case the Ocelot base url should be https://api.mybusiness.com. 
 
-If you are using containers and require Ocelot to respond to clients on http://123.12.1.1:6543
-then you can do this, however if you are deploying multiple Ocelot's you will probably want to pass this on the command line in some kind of script. Hopefully whatever scheduler you are using can pass the IP.
+If you are using containers and require Ocelot to respond to clients on http://123.12.1.1:6543 then you can do this, however if you are deploying multiple Ocelot's you will probably want to pass this on the command line in some kind of script. Hopefully whatever scheduler you are using can pass the IP.
 
 **Program**
 
-Then in your Program.cs you will want to have the following. The main things to note are 
-AddOcelot() (adds ocelot services), UseOcelot().Wait() (sets up all the Ocelot middleware).
+Then in your Program.cs you will want to have the following. The main things to note are  AddOcelot() (adds ocelot services), UseOcelot().Wait() (sets up all the Ocelot middleware).
 
 .. code-block:: csharp
 
@@ -116,8 +113,7 @@ AddOcelot() (adds ocelot services), UseOcelot().Wait() (sets up all the Ocelot m
 
 **Install NuGet package**
 
-Install Ocelot and it's dependecies using nuget. You will need to create a netcoreapp1.0+ projct and bring the package into it. Then follow the Startup below and :doc:`../features/configuration` sections
-to get up and running. Please note you will need to choose one of the Ocelot packages from the NuGet feed.
+Install Ocelot and it's dependecies using nuget. You will need to create a netcoreapp1.0+ projct and bring the package into it. Then follow the Startup below and :doc:`../features/configuration` sections to get up and running. Please note you will need to choose one of the Ocelot packages from the NuGet feed.
 
 All versions can be found `here <https://www.nuget.org/packages/Ocelot/>`_.
 

docs/introduction/notsupported.rst

@@ -7,10 +7,7 @@ Ocelot does not support...
 	
 * Forwarding a host header - The host header that you send to Ocelot will not be forwarded to the downstream service. Obviously this would break everything :(
 
-* Swagger - I have looked multiple times at building swagger.json out of the Ocelot ocelot.json but it doesnt fit into the vision 
-  I have for Ocelot. If you would like to have Swagger in Ocelot then you must roll your own swagger.json and do the following in your 
-  Startup.cs or Program.cs. The code sample below registers a piece of middleware that loads your hand rolled swagger.json and returns 
-  it on /swagger/v1/swagger.json. It then registers the SwaggerUI middleware from Swashbuckle.AspNetCore
+* Swagger - I have looked multiple times at building swagger.json out of the Ocelot ocelot.json but it doesnt fit into the vision I have for Ocelot. If you would like to have Swagger in Ocelot then you must roll your own swagger.json and do the following in your Startup.cs or Program.cs. The code sample below registers a piece of middleware that loads your hand rolled swagger.json and returns it on /swagger/v1/swagger.json. It then registers the SwaggerUI middleware from Swashbuckle.AspNetCore
 
 .. code-block:: csharp
 
@@ -28,16 +25,8 @@ Ocelot does not support...
 
     app.UseOcelot().Wait();
 
-The main reasons why I don't think Swagger makes sense is we already hand roll our definition in ocelot.json. 
-If we want people developing against Ocelot to be able to see what routes are available then either share the ocelot.json 
-with them (This should be as easy as granting access to a repo etc) or use the Ocelot administration API so that they can query Ocelot for the configuration.
+The main reasons why I don't think Swagger makes sense is we already hand roll our definition in ocelot.json. If we want people developing against Ocelot to be able to see what routes are available then either share the ocelot.json with them (This should be as easy as granting access to a repo etc) or use the Ocelot administration API so that they can query Ocelot for the configuration.
 
-In addition to this many people will configure Ocelot to proxy all traffic like /products/{everything} to their product service 
-and you would not be describing what is actually available if you parsed this and turned it into a Swagger path. Also Ocelot has 
-no concept of the models that the downstream services can return and linking to the above problem the same endpoint can return 
-multiple models. Ocelot does not know what models might be used in POST, PUT etc so it all gets a bit messy and finally the Swashbuckle 
-package doesnt reload swagger.json if it changes during runtime. Ocelot's configuration can change during runtime so the Swagger and Ocelot 
-information would not match. Unless I rolled my own Swagger implementation.
+In addition to this many people will configure Ocelot to proxy all traffic like /products/{everything} to their product service and you would not be describing what is actually available if you parsed this and turned it into a Swagger path. Also Ocelot has no concept of the models that the downstream services can return and linking to the above problem the same endpoint can return multiple models. Ocelot does not know what models might be used in POST, PUT etc so it all gets a bit messy and finally the Swashbuckle package doesnt reload swagger.json if it changes during runtime. Ocelot's configuration can change during runtime so the Swagger and Ocelot information would not match. Unless I rolled my own Swagger implementation.
 
-If the user wants something to easily test against the Ocelot API then I suggest using Postman as a simple way to do this. It might 
-even be possible to write something that maps ocelot.json to the postman json spec. However I don't intend to do this.
+If the user wants something to easily test against the Ocelot API then I suggest using Postman as a simple way to do this. It might even be possible to write something that maps ocelot.json to the postman json spec. However I don't intend to do this.