anchor.diff:  
   * 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.
  +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, Gorouter attempts to route the request to a different instance of the app. If 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.
  +### From Front-End Clients
  +
  +Gorouter supports keepalive connections from clients and does not close the TCP connection with clients immediately after returning an HTTP response. Clients are responsible for closing 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 %>
  +If keepalive connections are disabled, Gorouter closes the TCP connection with an app instance or system component after receiving an HTTP response.
  +
  +If keepalive connections are enabled, Gorouter maintains established TCP connections to back ends. Gorouter supports up to 100 idle connections to each back end:
  +
  +* If an idle connection exists for a given back end, Gorouter reuses it to route subsequent requests.
  +* If no idle connection exists for this back end, Gorouter creates a new connection.
  +
  +<% if vars.product_name.include? "CF" %> <%= vars.keepalive %> <% else %> <% end %>
  
positive.code: 
  ### <a id="forward-client-cert"></a> Forward Client Certificate to Applications
  
  Applications that require mutual TLS (mTLS) need metadata from client certificates to authorize requests. Cloud Foundry supports this use case without bypassing layer-7 load balancers and the Gorouter.
  
  The HTTP header `X-Forwarded-Client-Cert` (XFCC) may be used to pass the originating client certificate along the data path to the application. Each component in the data path must trust that the back-end component has not allowed the header to be tampered with.
  
  
negative.code: 
  <%= vars.zipkin_enable_link %>
  
  * If the `X-B3-TraceId` and `X-B3-SpanId` HTTP headers are not present in the request, Gorouter generates values for these and inserts the headers into the request forwarded to an application. These values are also found in Gorouter access log message for the request: `x_b3_traceid` and `x_b3_spanid`.
  * If both `X-B3-TraceId` and `X-B3-SpanId` HTTP headers are present in the request, Gorouter forwards the same value for `X-B3-TraceId`, generates a new value for `X-B3-SpanId`, and adds the `X-B3-ParentSpan` header, and sets to the value of the span id in the request. In addition to these trace and span ids, Gorouter access log message for the request includes `x_b3_parentspanid`.
  
  Developers can then add Zipkin trace IDs to their application logging in order to trace app requests and responses in Cloud Foundry.
  
  After adding Zipkin HTTP headers to app logs, developers can use `cf logs myapp` to correlate the trace and span ids logged by Gorouter with the trace ids logged by their app. To correlate trace IDs for a request through multiple apps, each app must forward appropriate values for the headers with requests to other applications.
  
  ### <a id="app-instance-routing"></a> HTTP Headers for App Instance Routing
  
  