anchor.diff:  
   ### <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.
  +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.
  +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.
  +- [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.
  +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:
   
  
positive.code: **Advantages:**
  
  - Adding route services requires no manual infrastructure configuration.
  - Traffic to apps that do not use the service makes fewer network hops because requests for those apps do not pass through the route service.
  
  **Disadvantages:**
  
  - Developers must manually provision and configure route services out of the context of <%= vars.app_runtime_abbr %> because no service broker automates these operations.
  - Traffic to apps that use the route service makes additional network hops, as compared to the static model.
  
  ### <a name="architecture-comparison"></a> Architecture Comparison
  
  The models above require the broker and service instance responsibilities summarized in the following table:
  
  <table id='architecture-comparison' border="1" class="nice" >
    <tr>
  
negative.code: 
  ## <a name='service-instance-responsibilities'></a> Service Instance Responsibilities
  
  The following applies only when a broker returns `route_service_url`
  in the bind response.
  
  ### <a name='how-it-works'></a> How It Works
  
  Binding a service instance to a route associates the
  `route_service_url` with the route in the <%= vars.app_runtime_abbr %>
  router. All requests for the route are proxied to the URL specified by
  `route_service_url`.
  
  Once a route service completes its function it may choose to forward
  the request to the originally requested URL or to another location, or
  it may choose to reject the request; rejected requests will be
  returned to the originating requestor. The <%= vars.app_runtime_abbr
  %> router includes a header that provides the originally requested
  URL, as well as two headers that are used by the router itself to
  validate the request sent by the route service. These headers are
  described in the sections below.
  
  ### <a name='headers'></a> Headers
  
  The following HTTP headers are added by the Gorouter to requests
  forwarded to route services.
  
  #### X-CF-Forwarded-Url
  
  The `X-CF-Forwarded-Url` header contains the originally requested
  URL. The route service may choose to forward the request to this URL
  or to another.
  
  #### X-CF-Proxy-Signature
  
  The `X-CF-Proxy-Signature` header contains an encrypted value which
  only the Gorouter can decrypt.
  
  The header contains the originally requested URL and a timestamp. When
  this header is present, the Gorouter rejects the request if the
  requested URL does not match that in the header, or if a timeout has
  expired.
  
  `X-CF-Proxy-Signature` also signals to the Gorouter that a request has
  transited a route service. If this header is present, the Gorouter
  does not forward the request to a route service, preventing recursive
  loops. For this reason, route services should not strip off the
  `X-CF-Proxy-Signature` and `X-CF-Proxy-Metadata` headers.
  
  If the route service forwards the request to a URL different from the
  originally requested one, and the URL resolves to a route for an app
  on <%= vars.app_runtime_abbr %>, the route must not have a bound route
  service or the request is rejected, as the requested URL does not
  match the one in the `X-CF-Proxy-Signature` header.
  
  #####= X-CF-Proxy-Metadata
  
  The `X-CF-Proxy-Metadata` header aids in the encryption and
  description of `X-CF-Proxy-Signature`.
  
  ### <a name='ssl-certs'></a> SSL Certificates
  
  When <%= vars.app_runtime_abbr %> is deployed in a development
  environment, certificates hosted by the load balancer are self-signed,
  and not signed by a trusted Certificate Authority. When the route
  service finishes processing an inbound request and makes a call to the
  value of `X-CF-Forwarded-Url`, be prepared to accept the self-signed
  certificate when integrating with a non-production deployment of <%=
  vars.app_runtime_abbr %>.
  
  ### <a name='timeouts'></a> Timeouts
  
  <% if vars.platform_code == 'CF' %>
  
  Route services must forward the
  request to the app route within the number of seconds configured by
  the `router.route_service_timeout` property. The
  `router.route_service_timeout` property defaults to 60 seconds.
  
  In addition, all requests must respond in the number of seconds
  configured by the `request_timeout_in_seconds` property. The
  `request_timeout_in_seconds` property default to 900 seconds.
  
  Timeouts are configurable for the router using the cf-release BOSH
  deployment manifest. For more information, see the [spec]
  (https://github.com/cloudfoundry-incubator/routing-release/blob/master/jobs/gorouter/spec).
  
  <% else %>
  
  Route services must forward the request to the app route
  within 60 seconds.
  
  In addition, all requests must respond in 900 seconds.
  
  