anchor.diff:  }
   ----
   
  +Note that while both secure and unsecure is possible with an OpenShift deployment, Red Hat recommends a secure routing service for a more secure deployment.
  +
   == Securing Routes
  -Creating a secure route to your pods can be accomplished by specifying the TLS Termination of the route and, optionally,
  -providing certificates to use. As of writing, OpenShift beta1 TLS termination relies on SNI for serving custom certificates (in the reference HAProxy implementation).
  -Any non-SNI traffic received on port 443 will have TLS terminated with a generic certificate.  In the future, the ability
  -to create custom frontends within the router will allow all traffic to serve custom certificates.
  +Creating a secure route to your pods can be accomplished by specifying the TLS Termination of the route and, optionally, providing certificates to use. As of writing, OpenShift beta1 TLS termination relies on SNI for serving custom certificates (in the reference HAProxy implementation). Any non-SNI traffic received on port 443 will have TLS terminated with a generic certificate. In the future, the ability to create custom frontends within the router will allow all traffic to serve custom certificates.
   
   There are three types of TLS termination:
   
   === Edge Termination
   Edge termination means that TLS termination occurs prior to traffic reaching the destination. TLS certificates are served by the frontend of the router.
   
  -Edge termination is configured by setting `TLS.Termination` to edge on your route and by specifying the `CACertificatFile`, `CertificateFile`
  -and `KeyFile`.
  +Edge termination is configured by setting `TLS.Termination` to edge on your route and by specifying the `CACertificatFile`, `CertificateFile` and `KeyFile`.
   
   ----
   {
  
positive.code: === Passthrough Termination
  Passthrough termination is a mechanism to send encrypted traffic straight to the destination without the router providing TLS termination.
  
  Passthrough termination is configured by setting `TLS.Termination` to passthrough on your route. No other information is required.
  The destination (such as an Nginx, Apache, or another HAProxy instance) will be responsible for serving certificates for the traffic.
  
  ----
  {
  
negative.code: 
  === Special Notes About Secure Routes
  
  At this point, password protected key files are not supported. HAProxy prompts you for a password when starting up and does not have a way to automate this process. We will need a follow up for KeyPassPhrase. To remove a passphrase from a keyfile you may run `openssl rsa -in passwordProtectedKey.key -out new.key`
  
  When creating a secure route you must include your certificate files as a single line of text.  To do this you simply replace the existing line breaks with `\\n`.  Please note the double slash which is required by the json spec.
  
  
  == Routers
  Currently, there is a single type of router plugin available in OpenShift, a template router.  A template router provides some infrastructure to the underlying router implementation:
  
  * Provides a wrapper that watches endpoints and routes
  * Saves endpoint and route data into a consumable form
  * Passes the internal state to a configurable template and executes the template
  * Calls a reload script
  
  Router plugins make the assumption that they can bind to host ports 80 and 443.  This is to allow external traffic to be routed to the host and subsequently through the router.  Routers also assume that networking is setup such that the router can access all other pods in the cluster.
  
  === The HAProxy Template Router
  
  The HAProxy template router implementation is the reference implementation for a template router plugin. This router implementation uses the `openshift/origin-haproxy-router` to run an HAProxy instance alongside the template router plugin. To help test routes, an install script is provided in `hack/install-router.sh`. The route script requires two parameters, the router id and the full url to the master.
  
  The script will attempt to create the router based on the generated json file if it can find the `osc` executable on the path. If it cannot find the executable it will simply create the json file and notify the user of the location. You can then manually run the create command.
  
  ----
  [vagrant@openshiftdev origin]$ hack/install-router.sh router https://10.0.2.15:8443
  