docs(*) Add Back to TOC link to all files of 0.14.x (#997)

* Add Back to TOC link to all files of 0.14.x

* Add line spaces and remove link at EOF

app/0.14.x/auth.md

@@ -27,6 +27,8 @@ then there is no consumer to be identified, and only the credentials will be add
 
 The authentication method specific elements and examples can be found in each [plugin's documentation][plugins].
 
+[Back to TOC](#table-of-contents)
+
 ## Consumers
 
 The easiest way to think about consumers is to map them one-on-one to users. Yet, to Kong this does not matter.
@@ -36,6 +38,8 @@ platform, e.g. an android consumer, an iOS consumer, etc.
 
 It is an opaque concept to Kong and hence they are called "consumers" and not "users".
 
+[Back to TOC](#table-of-contents)
+
 ## Anonymous Access
 
 Kong has the ability to configure a given Service to allow **both** authenticated **and** anonymous access.
@@ -178,6 +182,8 @@ the corresponding route:
 
     It shows the request was successful, but anonymous.
 
+[Back to TOC](#table-of-contents)
+
 ## Multiple Authentication
 
 Kong supports multiple authentication plugins for a given Service, allowing
@@ -211,5 +217,7 @@ tokens etc. will require authentication by the other configured auth plugins.
   configured on the anonymous consumer. Failure to do so will allow unauthorized requests.
 </div>
 
+[Back to TOC](#table-of-contents)
+
 [plugins]: https://konghq.com/plugins/
 [key-auth]: /plugins/key-authentication

app/0.14.x/configuration.md

@@ -147,6 +147,8 @@ For a list of Nginx directives, see https://nginx.org/en/docs/dirindex.html.
 Note however that some directives are dependent of specific Nginx modules,
 some of which may not be included with the official builds of Kong.
 
+[Back to TOC](#table-of-contents)
+
 ### Including files via injected Nginx directives
 
 For more complex configuration scenarios, such as adding entire new
@@ -196,6 +198,8 @@ path will be interpreted relative to the value of the `prefix` property of
 your `kong.conf` file (or the value of the `-p` flag of `kong start` if you
 used it to override the prefix when starting Kong).
 
+[Back to TOC](#table-of-contents)
+
 ## Custom Nginx templates & embedding Kong
 
 For the vast majority of use-cases, using the Nginx directive injection system
@@ -216,6 +220,8 @@ Nginx configuration and launch Kong using your customized template.
 can reuse Kong's generated configuration and include it in your existing
 configuration.
 
+[Back to TOC](#table-of-contents)
+
 ### Custom Nginx templates
 
 Kong can be started, reloaded and restarted with an `--nginx-conf` argument,

app/0.14.x/getting-started/adding-consumers.md

@@ -50,6 +50,8 @@ Congratulations! You've just added your first consumer to Kong.
 consumers][API-consumers] to associate a consumer with your existing user
 database.
 
+[Back to TOC](#table-of-contents)
+
 ## 2. Provision key credentials for your Consumer
 
 Now, we can create a key for our recently created consumer `Jason` by
@@ -61,6 +63,8 @@ $ curl -i -X POST \
   --data 'key=ENTER_KEY_HERE'
 ```
 
+[Back to TOC](#table-of-contents)
+
 ## 3. Verify that your Consumer credentials are valid
 
 We can now issue the following request to verify that the credentials of
@@ -73,6 +77,8 @@ $ curl -i -X GET \
   --header "apikey: ENTER_KEY_HERE"
 ```
 
+[Back to TOC](#table-of-contents)
+
 ## Next Steps
 
 Now that we've covered the basics of adding Services, Routes, Consumers and enabling

app/0.14.x/getting-started/configuring-a-service.md

@@ -62,6 +62,7 @@ Connection: keep-alive
 }
 ```
 
+[Back to TOC](#table-of-contents)
 
 ## 2. Add a Route for the Service
 
@@ -102,6 +103,8 @@ Connection: keep-alive
 
 Kong is now aware of your Service and ready to proxy requests.
 
+[Back to TOC](#table-of-contents)
+
 ## 3. Forward your requests through Kong
 
 Issue the following cURL request to verify that Kong is properly forwarding
@@ -125,6 +128,8 @@ the header defined in the above cURL request:
 
 <hr>
 
+[Back to TOC](#table-of-contents)
+
 ## Next Steps
 
 Now that you've added your Service to Kong, let's learn how to enable plugins.
@@ -134,4 +139,4 @@ Go to [Enabling Plugins &rsaquo;][enabling-plugins]
 [API]: /{{page.kong_version}}/admin-api
 [enabling-plugins]: /{{page.kong_version}}/getting-started/enabling-plugins
 [proxy-port]: /{{page.kong_version}}/configuration/#nginx-section
-[mockbin]: https://mockbin.com/
+[mockbin]: https://mockbin.com/

app/0.14.x/getting-started/enabling-plugins.md

@@ -39,6 +39,8 @@ $ curl -i -X POST \
 defaults to `['apikey']`. It is a list of headers and parameters names (both
 are supported) that are supposed to contain the apikey during a request.
 
+[Back to TOC](#table-of-contents)
+
 ## 2. Verify that the plugin is properly configured
 
 Issue the following cURL request to verify that the [key-auth][key-auth]
@@ -62,6 +64,8 @@ HTTP/1.1 401 Unauthorized
 }
 ```
 
+[Back to TOC](#table-of-contents)
+
 ## Next Steps
 
 Now that you've configured the **key-auth** plugin lets learn how to add

app/0.14.x/getting-started/introduction.md

@@ -20,6 +20,8 @@ To be more precise, Kong is a Lua application running in Nginx and made possible
 
 This sets the foundations for a pluggable architecture, where Lua scripts (referred to as *”plugins”*) can be enabled and executed at runtime. Because of this, we like to think of Kong as **a paragon of microservice architecture**: at its core, it implements database abstraction, routing and plugin management. Plugins can live in separate code bases and be injected anywhere into the request lifecycle, all in a few lines of code.
 
+[Back to TOC](#table-of-contents)
+
 ## Next Steps
 
 Now, lets get familiar with learning how to "start" and "stop" Kong.

app/0.14.x/getting-started/quickstart.md

@@ -35,6 +35,8 @@ $ kong start [-c /path/to/kong.conf]
 **Note:** the CLI accepts a configuration option (`-c /path/to/kong.conf`)
 allowing you to point to your own configuration.
 
+[Back to TOC](#table-of-contents)
+
 ## 2. Verify that Kong has started successfully
 
 If everything went well, you should see a message (`Kong started`)
@@ -50,6 +52,8 @@ By default Kong listens on the following ports:
 - `:8001` on which the [Admin API][API] used to configure Kong listens.
 - `:8444` on which the Admin API listens for HTTPS traffic.
 
+[Back to TOC](#table-of-contents)
+
 ## 3. Stop Kong
 
 As needed you can stop the Kong process by issuing the following
@@ -59,6 +63,8 @@ As needed you can stop the Kong process by issuing the following
 $ kong stop
 ```
 
+[Back to TOC](#table-of-contents)
+
 ## 4. Reload Kong
 
 Issue the following command to [reload][CLI] Kong without downtime:
@@ -67,6 +73,8 @@ Issue the following command to [reload][CLI] Kong without downtime:
 $ kong reload
 ```
 
+[Back to TOC](#table-of-contents)
+
 ## Next Steps
 
 Now that you have Kong running you can interact with the Admin API.
@@ -76,4 +84,4 @@ To begin, go to [Configuring a Service ›][configuring-a-service]
 [CLI]: /{{page.kong_version}}/cli
 [API]: /{{page.kong_version}}/admin-api
 [datastore-section]: /{{page.kong_version}}/configuration/#datastore-section
-[configuring-a-service]: /{{page.kong_version}}/getting-started/configuring-a-service
+[configuring-a-service]: /{{page.kong_version}}/getting-started/configuring-a-service

app/0.14.x/health-checks-circuit-breakers.md

@@ -122,6 +122,8 @@ Note:
    and does not limit the response. *Failing to do so might lead to health
    checks not being executed.*
 
+[Back to TOC](#table-of-contents)
+
 ## Types of health checks
 
 ### Active health checks
@@ -191,6 +193,8 @@ passive health checks to monitor the target health based solely on its
 traffic, and only use active health checks while the target is unhealthy,
 in order to re-enable it automatically.
 
+[Back to TOC](#table-of-contents)
+
 ## Enabling and disabling health checks
 
 ### Enabling active health checks
@@ -239,6 +243,8 @@ probes to consider a target unhealthy.
 active probes (as defined by `healthchecks.active.unhealthy.http_statuses`) to
 consider a target unhealthy.
 
+[Back to TOC](#table-of-contents)
+
 ### Enabling passive health checks
 
 Passive health checks do not feature a probe, as they work by interpreting
@@ -259,6 +265,8 @@ traffic to consider a target unhealthy, as observed by passive health checks.
 proxied traffic (as defined by `healthchecks.passive.unhealthy.http_statuses`)
 to consider a target unhealthy, as observed by passive health checks.
 
+[Back to TOC](#table-of-contents)
+
 ### Disabling health checks
 
 In all counter thresholds and intervals specified in the `healthchecks`

app/0.14.x/logging.md

@@ -142,3 +142,5 @@ proxy_access_log=logs/access.log show_everything if=$keeplog
 The final step in the process to make all the changes take effect is to restart kong. you can use the `kong restart` command to do so.
 
 Now, any requests made with an email address in it will no longer be logged. Of course, we can use this logic to remove anything we want from the logs on a conditional manner.
+
+[Back to TOC](#table-of-contents)

app/0.14.x/network.md

@@ -22,6 +22,8 @@ The proxy ports is where Kong receives its incoming traffic. There are two ports
 
 These are the **only ports** that should be made available to your clients.
 
+[Back to TOC](#table-of-contents)
+
 ### Management api
 
 This is the port where Kong exposes its management api. Hence in production this port should be firewalled to protect
@@ -30,6 +32,8 @@ it from unauthorized access.
 * `8001` provides Kong's **Admin API** that you can use to operate Kong. See [admin_listen].
 * `8444` provides the same Kong **Admin API** but using HTTPS. See [admin_listen] and the `ssl` suffix.
 
+[Back to TOC](#table-of-contents)
+
 ## Firewall
 
 Below are the recommended firewall settings:
@@ -39,6 +43,7 @@ Below are the recommended firewall settings:
 * If you are binding the Admin API to a public-facing interface (via [admin_listen]), then **protect** it to only allow trusted clients to access the Admin API.
   See also [Securing the Admin API][secure_admin_api].
 
+[Back to TOC](#table-of-contents)
 
 [proxy_listen]: /{{page.kong_version}}/configuration/#proxy_listen
 [admin_listen]: /{{page.kong_version}}/configuration/#admin_listen

app/0.14.x/plugin-development/access-the-datastore.md

@@ -53,6 +53,8 @@ local plugins_dao = kong.dao.plugins
 The `kong` global exposes the [Plugin Development Kit], and its `kong.dao` and
 `kong.db` properties are instances of the DAO and DB singletons.
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 ## The DAO Lua API
@@ -80,6 +82,8 @@ local inserted_plugin, err = kong.dao.plugins:insert({
 For a real-life example of the DAO being used in a plugin, see the
 [Key-Auth plugin source code](https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/handler.lua).
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 Next: [Custom Entities ›]({{page.book.next}})

app/0.14.x/plugin-development/admin-api.md

@@ -26,6 +26,8 @@ level of abstraction makes it easy for you to add endpoints.
 kong.plugins.<plugin_name>.api
 ```
 
+[Back to TOC](#table-of-contents)
+
 ## Adding endpoints to the Admin API
 
 Kong will detect and load your endpoints if they are defined in a module named:
@@ -74,6 +76,8 @@ other keys:
   errors](http://leafo.net/lapis/reference/exception_handling.html#capturing-recoverable-errors)
   documentation.
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 ## Helpers
@@ -129,6 +133,8 @@ return {
 See the [complete Admin API of the Key-Auth plugin](https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/api.lua)
 for an extended version of this example.
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 Next: [Write tests for your plugin]({{page.book.next}})

app/0.14.x/plugin-development/custom-entities.md

@@ -22,6 +22,10 @@ kong.plugins.<plugin_name>.schema.migrations
 kong.plugins.<plugin_name>.daos
 ```
 
+[Back to TOC](#table-of-contents)
+
+---
+
 ## Create a migration file
 
 Once you have defined your model, you must create your migration modules which
@@ -127,6 +131,8 @@ the `migrations` file.
 
 To see a real-life example, give a look at the [Key-Auth plugin migrations](https://github.com/Kong/kong/tree/master/kong/plugins/key-auth/migrations)
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 ## Retrieve your custom DAO from the DAO Factory
@@ -200,6 +206,8 @@ table of `daos.lua`.
 
 You can see an example of this in the [Key-Auth `daos.lua` file](https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/daos.lua).
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 ## Caching custom entities
@@ -217,6 +225,8 @@ The next chapter will focus on caching custom entities, and invalidating them
 when they change in the datastore: [Caching custom
 entities]({{page.book.next}}).
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 Next: [Caching custom entities &rsaquo;]({{page.book.next}})

app/0.14.x/plugin-development/custom-logic.md

@@ -23,6 +23,10 @@ namespaced under: `kong.plugins.<plugin_name>.handler`
 kong.plugins.<plugin_name>.handler
 ```
 
+[Back to TOC](#table-of-contents)
+
+---
+
 ## Available request contexts
 
 The plugins interface allows you to override any of the following methods in
@@ -53,6 +57,8 @@ chapter]({{page.book.next}}).
 [body_filter_by_lua]: https://github.com/openresty/lua-nginx-module#body_filter_by_lua
 [log_by_lua]: https://github.com/openresty/lua-nginx-module#log_by_lua
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 ## handler.lua specifications
@@ -183,6 +189,8 @@ return CustomHandler
 See [the source code of the Key-Auth plugin](https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/handler.lua) for an example of a real-life
 handler code.
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 ## Plugin Development Kit
@@ -199,6 +207,8 @@ When you are trying to implement some logic that needs to interact with Kong
 some error or debug information...), you should consult the [Plugin Development
 Kit Reference][pdk].
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 ## Plugins execution order
@@ -255,6 +265,8 @@ request-termination       | 2
 correlation-id            | 1
 post-function             | -1000
 
+[Back to TOC](#table-of-contents)
+
 ---
 
 Next: [Store configuration &rsaquo;]({{page.book.next}})