anchor.diff:  
   <strong><%= modified_date %></strong>
   
  -This topic describes how the Gorouter, the main component in Cloud Foundry's [routing](./architecture/#routing) tier, routes HTTP traffic within Cloud Foundry (CF).
  +This topic describes how Gorouter, the main component in Cloud Foundry's [routing](./architecture/#routing) tier, routes HTTP traffic within Cloud Foundry (CF).
   
   ## <a id="http-headers"></a>HTTP Headers ##
   
  -HTTP traffic passed from the Gorouter to an app includes the following HTTP headers:
  +HTTP traffic passed from Gorouter to an app includes the following HTTP headers:
   
   * `X-Forwarded-Proto` gives the scheme of the HTTP request from the client. The scheme is HTTP if the client made an insecure request or HTTPS if the client made a secure request. Developers can configure their apps to reject insecure requests by inspecting the HTTP headers of incoming traffic and rejecting traffic that includes `X-Forwarded-Proto` with the scheme of HTTP.
   
   * `X-Forwarded-For` gives the IP address of the client originating the request.
   
  -If your load balancer terminates TLS on the client side of the Gorouter, it must append these headers to requests forwarded to the Gorouter. <%= vars.http_routing %>
  +If your load balancer terminates TLS on the client side of Gorouter, it must append these headers to requests forwarded to Gorouter. <%= vars.http_routing %>
   
   ### <a id="zipkin-headers"></a> HTTP Headers for Zipkin Tracing
   
  
positive.code: 
  * On subsequent requests, the client must provide both the `JSESSIONID` and `VCAP_ID` cookies.
  
  The CF routing tier uses the `VCAP_ID` cookie to forward client requests to the same app instance every time. The `JSESSIONID` cookie is forwarded to the app instance to enable session continuity. If the app instance identified by the `VCAP_ID` crashes, the Gorouter attempts to route the request to a different instance of the app. If the Gorouter finds a healthy instance of the app, it initiates a new sticky session.
  
  <p class="note"><strong>Note</strong>: CF does not persist or replicate HTTP session data across app instances. If an app instance crashes or is stopped, session data for that instance is lost. If you require session data to persist across crashed or stopped instances, or to be shared by all instances of an app, store session data in a CF marketplace service that offers data persistence.</p>
  
  ## <a id="keepalive"></a>Keepalive Connections
  
  ### From Frontend Clients
  
  The Gorouter supports keepalive connections from clients; it does not close the TCP connection with clients immediately after returning an HTTP response. It is up to clients to close these connections.
  
  ### To Back-End Servers
  
  By default, the Gorouter closes the TCP connection with an app instance or system component after receiving an HTTP response.
  
  When Keepalive Connections is enabled, the Gorouter maintains established TCP connections to back ends, with a configurable maximum that limits the number of total idle connections from each Gorouter instance. The Gorouter reuses idle connections for routing of subsequent requests if one exists for the selected back end, lowering latency and increasing throughput. If no idle connection exists, the Gorouter establishes a new connection and maintains the connection unless it has reached its idle connections limit. The number of idle connections from each Gorouter instance to an individual back end is limited to 100. <% if vars.product_name == 'CF' || vars.product_name == 'PCF' %> <%= vars.keepalive %> <% else %> <% end %>
  
negative.code: 
  ## <a id="consistency"></a>Preventing Misrouting
  
  As CF manages and balances apps, the internal IP address and ports for app instances change. To keep Gorouter's routing tables current, a Route Emitter on each Diego cell sends a periodic update to all Gorouters through NATS, reminding them of the location of all app instances; the default frequency of these updates is 20 seconds. Gorouter tracks a time-to-live (TTL) for each route to back-end mapping; this TTL defaults to 120 seconds and is reset when Gorouter receives an updated registration message.
  
  Network partitions or NATS failures can cause Gorouter's routing table to fall out of sync, as CF continues to re-create containers across hosts to keep apps running. This can lead to routing of requests to incorrect destinations.
  
  You can configure Gorouter to handle this problem in two ways:
  
  <table border="1" id="gorouter-modes" class="nice">
    <tr><th>Consistency mode</th>
  