anchor.diff:      cf push logger
       ```
   
  -1. Create a user-provided service instance, and include the route of the logging route service you pushed as `route_service_url`. Be sure to use `https` for the scheme. Run:
  +1. Create a user-provided service instance, and include the route of
  +the logging route service you pushed as `route_service_url`. Be sure
  +to use `https` for the scheme. Run:
   
       ```
       cf create-user-provided-service mylogger -r https://logger.cf.example.com
       ```
   
  -1. Push a sample app like [Spring Music](https://github.com/cloudfoundry-samples/spring-music). By default, this creates a route `spring-music.cf.example.com`. Run:
  +1. Push a sample app like [Spring
  +Music](https://github.com/cloudfoundry-samples/spring-music). By
  +default, this creates a route `spring-music.cf.example.com`. Run:
   
       ```
       cf push spring-music
       ```
   
  -1. Bind the user-provided service instance to the route of your sample app. The `bind-route-service` command takes a route and a service instance; the route is specified in the following example by domain `cf.example.com` and hostname `spring-music`. Run:
  +1. Bind the user-provided service instance to the route of your sample
  +app. The `bind-route-service` command takes a route and a service
  +instance; the route is specified in the following example by domain
  +`cf.example.com` and hostname `spring-music`. Run:
   
       ```
       cf bind-route-service cf.example.com mylogger --hostname spring-music
  
positive.code: 
  ## <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.
  
  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.
  
  <% 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).
  <% 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>
  
  
  ## <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.
  
  <% end %>
  
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.
  
  