anchor.diff:  
   ## <a name='security-considerations'></a> Security Considerations
   
  -The contract between route services and the Gorouter, applicable for fully-brokered and user-provided models, enables a <%= vars.app_runtime_abbr %> operator to suggest whether or not requests forwarded from the route service to a load balancer are encrypted. The <%= vars.app_runtime_abbr %> operator makes this suggestion by setting the `router.route_services_recommend_https` manifest property.
  -
  -This suggestion does not allow the platform to guarantee that a route service obeys the scheme of the `X-Forwarded-Url` header. If a route service ignores the scheme and downgrades the request to plain text, a malicious actor can intercept the request and use or modify the data within it.
  +The contract between route services and the Gorouter, applicable for
  +fully-brokered and user-provided models, enables a <%=
  +vars.app_runtime_abbr %> operator to suggest whether or not requests
  +forwarded from the route service to a load balancer are encrypted. The
  +<%= vars.app_runtime_abbr %> operator makes this suggestion by setting
  +the `router.route_services_recommend_https` manifest property.
  +
  +This suggestion does not allow the platform to guarantee that a route
  +service obeys the scheme of the `X-Forwarded-Url` header. If a route
  +service ignores the scheme and downgrades the request to plain text, a
  +malicious actor can intercept the request and use or modify the data
  +within it.
   
   For increased security, follow these recommendations:
   
  -* A load balancer terminating TLS should sanitize and reset `X-Forwarded-Proto` based on whether the request it received was encrypted or not. Set the `router.sanitize_forwarded_proto: false` manifest property for the Gorouter.
  -
  -* A load balancer configured for TCP passthrough should sanitize and reset the header based on whether the request it received was encrypted or not. Set the `router.sanitize_forwarded_proto: true` manifest property for the Gorouter.
  +* A load balancer terminating TLS should sanitize and reset
  +  `X-Forwarded-Proto` based on whether the request it received was
  +  encrypted or not. Set the `router.sanitize_forwarded_proto: false`
  +  manifest property for the Gorouter.
  +
  +* A load balancer configured for TCP passthrough should sanitize and
  +  reset the header based on whether the request it received was
  +  encrypted or not. Set the `router.sanitize_forwarded_proto: true`
  +  manifest property for the Gorouter.
   
   <% if vars.platform_code.include? "CF" %>
  -For more information about securing traffic into <%= vars.app_runtime_abbr %>, see [Securing Traffic into <%= vars.app_runtime_abbr %>](../adminguide/securing-traffic.html).
  +  For more information about
  +  securing traffic into <%= vars.app_runtime_abbr %>, see [Securing
  +  Traffic into <%= vars.app_runtime_abbr %>]
  +  (../adminguide/securing-traffic.html).
   <% end %>
   
  -<p class='note'><strong>Note:</strong> When a route service is mapped to a route, the Gorouter sanitizes the <code>X-Forwarded-Proto</code> header once, even though requests pass through the Gorouter more than once.</p>
  +<p class='note'><strong>Note:</strong> When a route service is mapped
  +to a route, the Gorouter sanitizes the <code>X-Forwarded-Proto</code>
  +header once, even though requests pass through the Gorouter more than
  +once.</p>
   
   
   ## <a name='secure-route-services'></a> Recommendations for Securing Route Services
   
  -To best secure communications through route services, <%= vars.app_runtime_abbr %> operators should: 
  -
  -1. Set the `router.route_services_recommended_https: true` manifest property.
  -
  -1. Set the `router.disable_http: true` manifest property. Setting this property disables the HTTP listener, forcing all communication to the Gorouter to be HTTPS. This assumes all route services will communicate over HTTPS with the Gorouter. This causes requests from other clients made to port 80 to be rejected. You should confirm that clients of all apps make requests over TLS.
  -
  -1. Confirm that route services do not modify the value of the `X-Forwarded-Proto` header.
  +To best secure communications through route services, <%=
  +vars.app_runtime_abbr %> operators should:
  +
  +1. Set the `router.route_services_recommended_https: true` manifest
  +property.
  +
  +1. Set the `router.disable_http: true` manifest property. Setting this
  +property disables the HTTP listener, forcing all communication to the
  +Gorouter to be HTTPS. This assumes all route services will communicate
  +over HTTPS with the Gorouter. This causes requests from other clients
  +made to port 80 to be rejected. You should confirm that clients of all
  +apps make requests over TLS.
  +
  +1. Confirm that route services do not modify the value of the
  +`X-Forwarded-Proto` header.
   
   <% end %>
  
positive.code: 
  ### <a name='catalog'></a> Catalog Endpoint
  
  Brokers must include `requires: ["route_forwarding"]` for a service in the catalog endpoint. If this is not present, <%= vars.app_runtime_abbr %> does not permit users to bind an instance of the service to a route.
  
  ### <a name='binding'></a> Binding Endpoint
  
  When users bind a route to a service instance, <%= vars.app_runtime_abbr %> sends a bind request to the broker, including the route address with `bind_resource.route`. A route is an address used by clients to reach apps mapped to the route. The broker may return `route_service_url`, containing a URL where <%= vars.app_runtime_abbr %> should proxy requests for the route. This URL must have an `https` scheme, or the Cloud Controller rejects the binding. `route_service_url` is optional, and not returning this field enables a broker to dynamically configure a network component already in the request path for the route, requiring no change in the <%= vars.app_runtime_abbr %> router.
  
  For more information about bind requests, see the [Binding](./api.html#binding) section of the _Open Service Broker API (v2.13)_ spec on GitHub.
  
  
  ## <a name='examples'></a> Example Route Services
  
  - [Logging Route Service](https://github.com/cloudfoundry-samples/logging-route-service): This route service can be pushed as an app to <%= vars.app_runtime_abbr %>. It fulfills the service instance responsibilities above and logs requests received and sent. It can be used to see the route service integration in action by tailing its logs.
  
  - [Rate Limiting Route Service](https://github.com/cloudfoundry-samples/ratelimit-service): This example route service is a simple <%= vars.app_runtime_abbr %> app that provides rate limiting to control the rate of traffic to an app.
  
  - [Spring Boot Example](https://github.com/nebhale/route-service-example): Logs requests received and sent, written in Spring Boot.
  
  
  ## <a name='tutorial'></a> Tutorial
  
  The following instructions show how to use the [Logging Route Service](https://github.com/cloudfoundry-samples/logging-route-service) described in [Example Route Services](#examples) to verify that when a route service is bound to a route, requests for that route are proxied to the route service.
  
  For a video of this tutorial, see [Route Services in Pivotal Cloud Foundry 1.7](https://youtu.be/VaaZJE2E4jI) on YouTube.
  
  These commands requires the Cloud Foundry Command Line Interface (cf CLI) v6.16 or later.
  
  To use the logging route service:
  
  
negative.code:     cf logs logger
      ```
  
  1. Send a request to the sample app and view in the route service logs
  that the request is forwarded to it by running:
  
      ```
      curl spring-music.cf.example.com
  