escape unintentional formatting and attribute references

modules/ROOT/pages/authentication.adoc

@@ -12,7 +12,7 @@ Sync Gateway supports the following authentication methods:
 The user must be created on Sync Gateway before it can be used for authentication.
 Users can be created through the Sync Gateway Admin REST API or configuration file. 
 
-* *Admin REST API:* the user credentials (**username**/**password**) are passed in the request body to the link:admin-rest-api.html#/user/post__db___user_[POST /{db}/_user] endpoint.
+* *Admin REST API:* the user credentials (**username**/**password**) are passed in the request body to the link:admin-rest-api.html#/user/post\__db___user_[+POST /{db}/_user+] endpoint.
 +
 
 [source,bash]
@@ -107,7 +107,7 @@ Example:
 Sync Gateway supports OpenID Connect.
 This allows your application to use Couchbase for data synchronization and delegate the authentication to a 3rd party server (known as the Provider). There are two implementation methods available with OpenID Connect: 
 
-* link:authentication.html#implicit-flow[Implicit Flow]: with this method, the retrieval of the ID token takes place on the device. You can then create a user session using the POST `/{db}/_session` endpoint on the Public REST API with the ID token. 
+* link:authentication.html#implicit-flow[Implicit Flow]: with this method, the retrieval of the ID token takes place on the device. You can then create a user session using the POST `+/{db}/_session+` endpoint on the Public REST API with the ID token. 
 * link:authentication.html#authorization-code-flow[Authorization Code Flow]: this method relies on Sync Gateway to retrieve the ID token. 
 
 
@@ -162,7 +162,7 @@ image::images.003.png[]
 
 
 . The Google SignIn SDK prompts the user to login and if successful it returns an ID token to the application. 
-. The ID token is used to create a Sync Gateway session by sending a POST `/{db}/_session` request. 
+. The ID token is used to create a Sync Gateway session by sending a POST `+/{db}/_session+` request. 
 . Sync Gateway returns a cookie session in the response header. 
 . The Sync Gateway cookie session is used on the replicator object. 
 
@@ -174,4 +174,4 @@ You can configure your application for Google SignIn by following https://develo
 === Authorization Code Flow
 
 Whilst Sync Gateway supports http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow], there is considerable work involved to implement the *Authorization Code Flow* on the client side.
-Couchbase Lite 1.x has an API to hide this complexity called `OpenIDConnectAuthenticator` but since it is not available in the 2.0 API we recommend to use the **Implicit Flow**. 
+Couchbase Lite 1.x has an API to hide this complexity called `OpenIDConnectAuthenticator` but since it is not available in the 2.0 API we recommend to use the **Implicit Flow**. 

modules/ROOT/pages/database-offline.adoc

@@ -19,13 +19,13 @@ Specific uses for the database offline/online functionality include:
 
 == Sync Gateway
 
-* Taking a database offline: link:admin-rest-api.html#!/database/post_db_offline[POST /{db}/_offline]
-* Taking a database online: link:admin-rest-api.html#!/database/post_db_online[POST /{db}/_online]
+* Taking a database offline: link:admin-rest-api.html#!/database/post_db_offline[+POST /{db}/_offline+]
+* Taking a database online: link:admin-rest-api.html#!/database/post_db_online[+POST /{db}/_online+]
 
 By default, when Sync Gateway starts, it brings all databases that are defined in the configuration file online.
 To keep a database offline when Sync Gateway starts, you can add the `offline` configuration property to the database configuration properties for the database, with the value `true` (see link:config-properties.html#foo_db[database properties]).
 
-Later, to bring the database online, you can use the `POST /{db}/_online` Admin REST API request. 
+Later, to bring the database online, you can use the `+POST /{db}/_online+` Admin REST API request. 
 
 === Offline state triggers
 

modules/ROOT/pages/integrating-external-stores.adoc

@@ -107,7 +107,7 @@ Here's what the code above is doing:
 
 . Use the https://github.com/request/request-promise[request-promise] library to retrieve the movies from the external store. 
 . Save the movies to Sync Gateway. The `post_db_bulk_docs` method takes a db name (``movies_lister``) and the documents to save in the request body. Notice that the response from the external store is an array and must be wrapped in a JSON object of the form ``{docs: movies}``. 
-. The response of the `/{db}/_bulk_docs` request contains the generated revision numbers which are written back to the external store. 
+. The response of the `+/{db}/_bulk_docs+` request contains the generated revision numbers which are written back to the external store. 
 
 
 [quote]
@@ -307,7 +307,7 @@ The documents are saved with the attachment metadata.
 
 image::admin-ui-attachment.png[]
 
-You can view the thumbnail at `http://localhost:4984/movies_lister/{db}/{doc}/{attachment}/` (note it's on the public port 4984). 
+You can view the thumbnail at `+http://localhost:4984/movies_lister/{db}/{doc}/{attachment}/+` (note it's on the public port 4984). 
 
 
 image::sg-attachment.png[]

modules/ROOT/pages/release-notes.adoc

@@ -99,7 +99,7 @@ If not, Sync Gateway will drop and recreate the index.
 Then, Sync Gateway will wait until indexes are available before starting to serve requests. 
 
 Sync Gateway 2.1 will *not* automatically remove the previously used design documents.
-Removal of the obsolete design documents is done via a call to the new link:admin-rest-api.html#/server/post__post_upgrade[/{db}/_post_upgrade] endpoint in Sync Gateway`'s Admin REST API.
+Removal of the obsolete design documents is done via a call to the new link:admin-rest-api.html#/server/post__post_upgrade[+/{db}/_post_upgrade+] endpoint in Sync Gateway`'s Admin REST API.
 This endpoint can be run in preview mode (``?preview=true``) to see which design documents would be removed.
 To summarize, the steps to perform an upgrade to Sync Gateway 2.1 are: 
 

modules/ROOT/pages/resolving-conflicts.adoc

@@ -35,7 +35,7 @@ curl -X POST http://localhost:4985/sync_gateway/_bulk_docs \
   -d '{"new_edits": false, "docs": [{"_id": "bar", "type": "task", "name": "aaa", "_rev": "1-123"}, {"_id": "bar", "type": "task", "name": "ccc", "_rev": "1-456"}, {"_id": "bar", "type": "task", "name": "bbb", "_rev": "1-789"}]}'
 ----
 
-It can be set in the request body of the POST `/{db}/_bulk_docs` endpoint. 
+It can be set in the request body of the POST `+/{db}/_bulk_docs+` endpoint. 
 
 == Detecting a conflict
 
@@ -241,4 +241,4 @@ Document with ID foo has 1 revisions.
 Document with ID bar has 1 revisions.
 ----
 
-Add more conflicting revisions from the command-line with a different document ID (baz for example). The conflict is resolved and the program continues to listen for the next change(s). 
+Add more conflicting revisions from the command-line with a different document ID (baz for example). The conflict is resolved and the program continues to listen for the next change(s). 

modules/ROOT/pages/rest-api-client.adoc

@@ -39,7 +39,7 @@ Here, you're enabling CORS on ``http://localhost:8000``, the hostname of the web
 
 ~/Downloads/couchbase-sync-gateway/bin/sync_gateway sync-gateway-config.json
 ----
-. Insert a few documents using the POST `/{db}/_bulk_docs` endpoint 
+. Insert a few documents using the POST `+/{db}/_bulk_docs+` endpoint 
 +
 
 [source,bash]

modules/ROOT/pages/rest-api.adoc

@@ -63,4 +63,4 @@ const ui = SwaggerUIBundle({
 })
 window.ui = ui
 </script>
-++++
+++++

modules/ROOT/pages/server-integration.adoc

@@ -60,7 +60,7 @@ Here's a table that compares each API in different scenarios:
 
 This article describes how to use the changes feed API to integrate Sync Gateway with other backend processes. For instance if you have a channel called "needs-email" you could have a bot that sends an email and then saves the document back with a flag to keep it out of the "needs-email" channel.
 
-The changes feed API is a REST API endpoint (xref:sync-gateway-public.adoc#/database/get\__db___changes[`/{db}/_changes`]) that returns a sorted list of changes made to documents in the database. It permits applications to implement business logic that reacts to changes in documents. There are several methods of connecting to the changes feed (also know as the feed type). The first 3 methods (`polling`, `longpoll` and `continuous`) are based on the CouchDB API. The last method (`websocket`) is specific to Sync Gateway.
+The changes feed API is a REST API endpoint (xref:sync-gateway-public.adoc#/database/get\__db___changes[`+/{db}/_changes+`]) that returns a sorted list of changes made to documents in the database. It permits applications to implement business logic that reacts to changes in documents. There are several methods of connecting to the changes feed (also know as the feed type). The first 3 methods (`polling`, `longpoll` and `continuous`) are based on the CouchDB API. The last method (`websocket`) is specific to Sync Gateway.
 
 - link:http://guide.couchdb.org/draft/notifications.html#polling[polling] (default): returns the list of changes immediately. A new request must be sent to get the next set of changes.
 - link:http://guide.couchdb.org/draft/notifications.html#long[longpolling]: in addition to regular polling, if the request is sent with a special `last_seq` parameter, it will stay open until a new change occurs and is posted.
@@ -182,4 +182,4 @@ The `filter` function in the second handler recognizes documents with `doc.type`
         }
      ]
   }
-----
+----

modules/ROOT/pages/shared-bucket-access.adoc

@@ -54,8 +54,8 @@ The reference to the configuration API changes can be found below.
 
 When this feature is enabled, the REST API will include the following changes. 
 
-* Sync Gateway purging (link:admin-rest-api.html?v=1.5#/document/post__db___purge[/{db}/_purge]) removes the document and its associated extended attributes.
-* Sync Gateway document expiry (PUT link:admin-rest-api.html?v=1.5#/document/put__db___doc_[/{db}/{docid}]) will tombstone the active revision.
+* Sync Gateway purging (link:admin-rest-api.html?v=1.5#/document/post\__db___purge[+/{db}/_purge+]) removes the document and its associated extended attributes.
+* Sync Gateway document expiry (PUT link:admin-rest-api.html?v=1.5#/document/put\__db___doc_[+/{db}/{docid}+]) will tombstone the active revision.
 
 
 == Tombstones

modules/ROOT/pages/sync-function-api.adoc

@@ -266,7 +266,7 @@ expiry("2018-07-06T17:00:00+01:00")
 Under the hood, the expiration time is set and managed on the Couchbase Server document (TTL is not supported for databases in walrus mode). The value can be specified in two ways: 
 
 * *ISO-8601 format:* for example the 6th of July 2016 at 17:00 in the BST timezone would be ``2016-07-06T17:00:00+01:00``; 
-* *as a numeric Couchbase Server expiry value:* Couchbase Server expiries are specified as Unix time, and if the desired TTL is below 30 days then it can also represent an interval in seconds from the current time (for example, a value of 5 will remove the document 5 seconds after it is written to Couchbase Server). The document expiration time is returned in the response of GET link:rest-api.html#/document/get__db___doc_[/{db}/{doc}] when `show_exp=true` is included in the querystring.
+* *as a numeric Couchbase Server expiry value:* Couchbase Server expiries are specified as Unix time, and if the desired TTL is below 30 days then it can also represent an interval in seconds from the current time (for example, a value of 5 will remove the document 5 seconds after it is written to Couchbase Server). The document expiration time is returned in the response of GET link:rest-api.html#/document/get\__db___doc_[+/{db}/{doc}+] when `show_exp=true` is included in the querystring.
 
 As with the existing explicit purge mechanism, this applies only to the local database; it has nothing to do with replication.
 This expiration time is not propagated when the document is replicated.
@@ -344,12 +344,12 @@ To update the Sync Function, it is recommended to follow the steps outlined belo
 
 . Update the configuration file of the Sync Gateway instance. 
 . Restart Sync Gateway. 
-. Take the database offline using the link:admin-rest-api.html#!/database/post_db_offline[/{db}/_offline] endpoint.
+. Take the database offline using the link:admin-rest-api.html#!/database/post_db_offline[+/{db}/_offline+] endpoint.
 . Call the re-sync endpoint on the Admin REST API. The message body of the response contains the number of changes that were made as a result of calling re-sync. 
-. Bring the database back online using the link:admin-rest-api.html#!/database/post_db_online[/{db}/_online] endpoint.
+. Bring the database back online using the link:admin-rest-api.html#!/database/post_db_online[+/{db}/_online+] endpoint.
 
 This is an expensive operation because it requires every document in the database to be processed by the new function.
-The database can't accept any requests until this process is complete (because no user's full access privileges are known until all documents have been scanned). Therefore the Sync Function update will result in application downtime between the call to the `/{db}/_offline` and `/{db}/_online` endpoints as mentioned above. 
+The database can't accept any requests until this process is complete (because no user's full access privileges are known until all documents have been scanned). Therefore the Sync Function update will result in application downtime between the call to the `+/{db}/_offline+` and `+/{db}/_online+` endpoints as mentioned above. 
 
 === When should you run a re-sync?
 
@@ -365,6 +365,6 @@ Similarly, if you wish to change the channel/access rules, but only want those r
 If you need to ensure access to the database during the update, you can create a read-only backup of the Sync Gateway's bucket beforehand, then run a secondary Sync Gateway on the backup bucket, in read-only mode.
 After the update is complete, switch to the main Gateway and bucket. 
 
-In a clustered environment with multiple Sync Gateway instances sharing the load, all the instances need to share the same configuration, so they all need to be taken offline either by stopping the process or taking them offline using the link:admin-rest-api.html#!/database/post_db_offline[/{db}/_offline] endpoint.
+In a clustered environment with multiple Sync Gateway instances sharing the load, all the instances need to share the same configuration, so they all need to be taken offline either by stopping the process or taking them offline using the link:admin-rest-api.html#!/database/post_db_offline[+/{db}/_offline+] endpoint.
 After the configuration is updated, *one* instance should be brought up so it can update the database -- if more than one is running at this time, they'll conflict with each other.
-After the first instance finishes opening the database, the others can be started. 
+After the first instance finishes opening the database, the others can be started.