Wapp

  +  **wapp-cache-control** _CONTROL_  
     The _CONTROL_ argument should be one of "no-cache", "max-age=N", or
     "private,max-age=N", where N is an integer number of seconds.

  +  **wapp-content-security-policy** _POLICY_  
     Set the Content Security Policy (hereafter "CSP") to _POLICY_.  The
     default CSP is _default\_src 'self'_, which is very restrictive.  The
     default CSP disallows (a) loading any resources from other origins,
     (b) the use of eval(), and (c) in-line javascript or CSS of any kind.
     Set _POLICY_ to "off" to completely disable the CSP mechanism.  Or
     specify some other policy suitable for the needs of the application.

  +  **wapp-debug-env**  
     This routine returns text that describes all of the Wapp parameters.

To run this same program as a traditional web-server on TCP port 8080, enter:

>
    wapptclsh main.tcl --server 8080

Here the built-in web-server listens on all IP addresses and so the
web page is available on other machines.  But the web-brwser is not
automatically started in this case, so you will have to manually enter
"http://localhost:8080/" into your web-browser in order to see the page.

To run this program as CGI, put the main.tcl script in your web-servers
file hierarchy, in the appropriate place for CGI scripts, and make any
other web-server specific configuration changes so that the web-server
understands that the main.tcl file is a CGI script.  Then point your

      name are silently ignored.  Furthermore, query parameters are only
      decoded if the HTTP request uses the same origin as the application,
      or if the "wapp-allow-xorigin-params" has been run to signal Wapp
      that cross-origin query parameters are allowed.

  4.  **POST Parameters**  
      POST parameters are the application/x-www-form-urlencoded key/value
      pairs in the content of a POST request that typically originate from
      forms.  POST parameters are treated exactly like query parameters in
      that they are decoded to form new Wapp parameters as long as they
      have all lower-case keys and as long as either the HTTP request comes
      from the same origin or the "wapp-allow-xorigin-params" command has
      been run.
      
All Wapp parameters are held in a single namespace.  There is no way to

|REQUEST\_METHOD|→|"GET" or "POST" or "HEAD"|
|SAME\_ORIGIN|→|True if this request is from the same origin|
|SCRIPT\_FILENAME|→|Full pathname of the Wapp application script|
|SCRIPT\_NAME|→|Prefix of PATH\_INFO that identifies the application script|
|SELF\_URL|→|URL of this request without PATH\_TAIL|
|WAPP\_MODE|→|One of "cgi", "scgi", "server", or "local"|

4.0 URL Parsing
---------------

Assuming "env.tcl" is the name of the Wapp application script:

>
    https://wapp.tcl.tk/demo/env.tcl/abc/def/ghi?a=5&b=22.425#point42
            \_________/ \__________/\__________/

2.0 URL Mapping
---------------

The URL Mapper is the function that determines which routine in the
application should handle an HTTP request based on the URL.  In Wapp,
the default URL Mapper simply looks at PATH\_HEAD and invokes the
application-defined proc name "wapp-page-$PATH\_HEAD".  If no such
proc exists, then Wapp invokes the application-defined proc "wapp-default".

2.1 Customizing The URL Mapper
------------------------------

Just prior to dispatch of the HTTP request handler, Wapp invokes a
proc named "wapp-before-dispatch-hook".  This proc is normally a no-op.
But, applications can redefine the "wapp-before-dispatch-hook" proc to
make modifications to the environment prior to dispatch.  So, for example,
a custom wapp-before-dispatch-hook function can change the value of
the PATH\_HEAD parameter to cause a different request handler to be invoked.

The [checklist](https://sqlite.org/checklistapp) application does this.
See [these lines](https://sqlite.org/checklistapp/artifact/8f94882fa0?ln=715-744)
for the implementation.  If the original PATH\_HEAD is really the name of
a checklist database, then that name is moved to a new parameter called
OBJECT, and PATH\_HEAD is shifted to be the next element of PATH\_TAIL.
In this way, the PATH\_INFO for checklist is parsed into OBJECT/METHOD
rather than just a METHOD.

This is but one example.  Applications can make creative use of
the "wapp-before-dispatch-hook" to make whatever changes are appropriate
for the task at hand.

Web Applications Using Wapp
===========================

The following are some of the known uses of Wapp in the wild:

  1.  The [checklist](https://sqlite.org/checklists) application used to
      manage testing and release of SQLite is a Wapp script.
      Source code for the checklist
      application is at <https://sqlite.org/checklistapp>.

  2.  The [skins page](https://fossil-scm.org/skins) of Fossil is implemented
      as a simple [Wapp script](https://fossil-scm.org/skins/wapp-script.txt).

  3.  The [search feature](https://sqlite.org/search?q=fts5) on the SQLite
      homepage is implemented using a Wapp-script, seen
      [here](https://sqlite.org/docsrc/file/search/search.tcl.in).
      (NB: The search.tcl.in script is processed using
      [mkscript.tcl](https://sqlite.org/docsrc/file/search/mkscript.tcl)
      prior to being deployed.)