anchor.diff:  
   Twixt must do all necessary compilations and other transformations, to arrive at final content for which a checksum
   can be computed.
  -This is also good because any exceptions, such as compilation errors, will occur immediately (when
  -initially rendering the page), rather than when the asset's content is later retrieved by the client.
  +Although this can slow the initial HTML render, it is also good because any exceptions, such as compilation errors, will occur immediately,
  +rather than when the asset's content is later retrieved by the client.
   
   When a client requests an asset that exists, but supplies an incorrect checksum,
   Twixt will respond with a 301 redirect HTTP response,
  
positive.code: This prevents a malicious client from directly accessing your code or configuration files.
  Anything outside the +META-INF/assets/+ folder is inaccessible via Twixt.
  
  Twixt maps file extensions to MIME types; it then will transform certain MIME types; for example +.coffee+ files are compiled to JavaScript.
  
  [source,clojure]
  ----
  
negative.code: == Direct asset URLs
  
  Sometimes it is not possible to determine the full asset URL ahead of time; a common example would be a client-side
  framework, such as http://angularjs.org[AngularJS] that wants to load HTML templates dynamically, at runtime.  It will know
  the path to the asset, but will not know the checksum.
  
  In this case, an *optional* Ring middleware can be used: +wrap-with-asset-redirector+.
  
  This middleware identifies requests that match existing assets and responds with a 302 redirect to the proper asset URL.
  For example, the asset stored as +META-INF/assets/blueant/cla.html+ can be accessed as +/blueant/cla.html+, and will be sent a redirect
  