anchor.diff:  
   *Sticky Sessions*
   
  -Implementing sticky sessions is up to the underlying router configuration.  The default HAProxy
  -template implements sticky sessions using the `balance source` directive which balances based
  -on the source IP.  In addition, the template router plugin will provide the service name and
  -namespace to the underlying implementation.  This can be used for more advanced configuration
  -such as implementing stick-tables that synchronize between a set of peers. For details on the
  -implementation you may inspect the `haproxy-config.template` located in the `/var/lib/haproxy/conf`
  -directory of your router container.
  +Sticky sessions are implemented by the underlying router configuration. The
  +default
  +link:https://github.com/openshift/origin/blob/3dc5a6e7416a9a6f2270cc236b26be7abb491ab0/images/router/haproxy/conf/haproxy-config.template[HAProxy
  +template] in the `/var/lib/haproxy/conf` directory of the router container
  +configures sticky sessions using the `balance source` directive, which balances
  +based on the source IP. In addition, the template router plug-in provides the
  +service name and namespace to the underlying implementation. This can be used
  +for more advanced configurations, such as implementing stick-tables to
  +synchronize peers.
   
   ////
   == Highly-available Routers
  
positive.code: - WebSockets
  - TLS with SNI
  
  NOTE: WebSocket traffic uses the same route conventions and supports the same
  TLS termination types as other traffic.
  
  The router uses the service selector to watch the endpoints that support the
  service, bypassing its logic and replacing it with the router's own. Routers
  subscribe to a configuration and automatically update themselves with any
  changes. Router may be containerized or virtual, converting any changes to API
  calls to another system, such as *F5*.
  
  Other capabilities exist to load-balance a service within a cluster. These
  services are exposed via a configurable link relation between different
  
negative.code: [[wildcard-certificates]]
  *Wildcard Certificates*
  
  Depending on your implementation, you can use a default certificate. Default
  certificates are useful for implementing a wildcard certificate for the router.
  For example, if you have many routes that end in `example.com` you may wish to
  install a router with a wildcard certificate for `*.example.com`.
  
  To provide the default certificate to the router you must specify it in the
  create command with the `--default-cert` option. The certificate should be a
  concatenated file of the key, certificate, and any CA certificates that are
  required by the browser. The certificate must be in a form acceptable by the
  underlying router implementation. In the case of HAProxy it should be a
  PEM-based certificate.
  
  ----
  $ oadm router --credentials="$KUBECONFIG" --default-cert=/full/path/to/certificate.pem
  ----
  
  For HAProxy, if a default certificate is provided, it will be loaded first. The
  certificate that is loaded first is presented to any route that matches the CN
  on the certificate and any route that is secure but does not match any
  configured certificates. For example, if the default certificate is for
  `\*.example.com` and a secure route for `www.foo.com` is created with no
  certificates the route will still be written and the router will serve the
  `*.example.com` certficiate. This may result in a browser warning for users
  since the CN on the certificate does not match the url. If no default
  certificate is supplied, the HAProxy router will default to a generic, expired
  certificate that is provided in the base image.
  
  [[special-notes]]
  