anchor.diff:      <th width="30%">X-Cf-Routererror Value</th>
       <th width="30%">Reason for Error</th>
       <th width="40%">Response Body</th>
  -  </tr> 
  +  </tr>
     <tr>
       <td><code>invalid_cf_app_instance_header</code></td>
       <td>The value provided for <code>X-Cf-App-Instance</code> was not a properly formatted GUID.</td>
  
positive.code:     <td><code>unknown_route</code></td>
      <td>The value provided for <code>X-Cf-App-Instance</code> is a correctly formatted GUID, but there is no instance found with that guid for the route requested.</td>
      <td><code>400 Bad Request: Requested instance ('1') with guid ('aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa') does not exist for route ('myroute.cf.com')</code></td>
    </tr>  
  </table> 
  
  ### <a id="forward-client-cert"></a> Forward Client Certificate to Apps
  
  
negative.code: 
  With sticky sessions, when multiple instances of an app are running on <%= vars.app_runtime_abbr %> requests from a particular client always reach the same app instance. This allows apps to store session data specific to a user session.
  
  * To support sticky sessions, configure your app to return a sticky session cookie in responses.
  The default value for this field is `JSESSIONID`.
  You can configure the cookie names that the routing tier uses for sticky sessions.
  <% if vars.platform_code == 'CF' %>To configure the names of the cookies, edit the
  `router.sticky_session_cookie_names` config key in your manifest.
  <% else %> <%= vars.tas_networking %> <% end %>
  
  * If an app returns a sticky session cookie to a client request, the CF routing tier generates a unique `VCAP_ID` for the app instance based on its GUID in the following format:
  <pre class="terminal">
  323f211e-fea3-4161-9bd1-615392327913
  </pre>
  