Wapp

  *   A complete application is contained in a single file
  *   Resistant to attacks and exploits
  *   Cross-platform → CGI, SCGI, or a built-in web server
  *   The MVC design pattern is supported but not required
  *   The Wapp framework itself is a  single-file TCL script
      that is "source"-ed, "package require"-ed, 
      or even copy/pasted into the application TCL script
  *   The framework can easily be embedded within a larger application
      to provide a web-based monitoring capability to an existing
      code base
  *   2-clause BSD license


2.0 Hello World
---------------

Here is a minimal web application written using Wapp:

of Wapp.  The other interfaces are merely details.

The following is a complete list of the public interface procs in Wapp:

  +  **wapp-start** _ARGLIST_  
     Start up the application.  _ARGLIST_ is typically the value of $::argv,
     though it might be some subset of $::argv if the containing application
     has already processed some command-line parameters for itself.  By default,
     this proc never returns, and so it should be very last command in the
     application script.  To embed Wapp in a larger application, include
     the -nowait option in _ARGLIST_ and this proc will return immediately
     after setting up all necessary file events.

  +  **wapp-subst** _TEXT_  
     This command appends text to the end of reply to an HTTP request.
     The _TEXT_ argument should be enclosed in {...} to prevent substitutions.
     The "wapp-subst" command itself will do all necessary backslash
     substitutions.  Command and variable substitutions only occur within
     "%html(...)", "%url(...)", "%qp(...)", "%string(...)", and

Parameter values in the original HTTP request may be encoded in various
ways.  Wapp decodes parameter values before returning them to the
application.  Application developers never see the encoded values.
There is never an opportunity to miss a decoding step.

For security reasons, Query and POST parameters are only added to the
Wapp parameter set if the inbound request is from the "same origin" or
if the special "wapp-allow-xorigin-params" interface is called.
An inbound request is from the same origin if it is in response to
clicking on a hyperlink or form on a page that was generated by the
same website.
Manually typing in a URL does not constitute the "same origin".  Hence,
in the "env.tcl" example above the "wapp-allow-xorigin-params" interface
is used so that you can manually extend the URL to add new query parameters.

If query parameters can have side effects, then you should omit the
wapp-allow-xorigin-params call.  Only invoke wapp-allow-xorigin-params
for web pages that only query information.  Do not invoke
wapp-allow-xorigin-params on pages where the parameters can be used
to change server-side state.

3.0 CGI Parameter Details
-------------------------

The CGI parameters in Wapp describe the HTTP request that is to be answered
and the execution environment.
These parameter look like CGI environment variables.  To prevent environment
information from overlapping and overwriting query parameters, all the
environment information uses upper-case names and all query parameters
are required to be lower case.  If an input URL contains an upper-case
query parameter (or POST parameter or cookie), that parameter is silently
omitted.

The following CGI parameters are available:

  +  **CONTENT\_LENGTH**  
     The number of bytes of POST data.
     This parameter is either omitted or has a value of "0"
     for non-POST requests.

  +  **CONTENT\_TYPE**  
     The mimetype of the POST data.  Usually this is
     application/x-www-form-urlencoded.
     This parameter is omitted for non-POST requests.

  +  **DOCUMENT\_ROOT**