http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/Building.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/Building.md 
b/thirdparty/civetweb-1.10/docs/Building.md
new file mode 100644
index 0000000..9d7b56f
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/Building.md
@@ -0,0 +1,216 @@
+Building CivetWeb
+=========
+
+This guide covers the build instructions for the stand-alone web server.
+See 
[Embedding.md](https://github.com/civetweb/civetweb/blob/master/docs/Embedding.md)
 for information on extending an existing C or C++ application. A brief 
overview of the source code files can be found in 
[Embedding.md](https://github.com/civetweb/civetweb/blob/master/docs/Embedding.md)
 as well.
+
+#### Where to get the source code?
+
+The latest version can be found at
+https://github.com/civetweb/civetweb
+
+Released versions can be found at
+https://github.com/civetweb/civetweb/releases
+
+
+Building for Windows
+---------
+
+#### Using Visual Studio
+
+Open the *VS/civetweb.sln* in Visual Studio.
+To include SSL support, you may have to add an extra library for the 
cryptography support. You might wish to use yaSSL.  However, it is GPL licensed 
or uses a commercial license. See 
[yaSSL.md](https://github.com/civetweb/civetweb/blob/master/docs/yaSSL.md) for 
more information.
+Alternatively, you might wish to use OpenSSL. See 
[OpenSSL.md](https://github.com/civetweb/civetweb/blob/master/docs/OpenSSL.md) 
for more information.
+
+#### Using MinGW-w64 or TDM-GCC
+In the start menu locate and run the "Run terminal" batch file. For TDM-GCC 
this is named "MinGW Command Prompt".
+Navigate to the civetweb sources directory and run:
+```
+mingw32-make CC=gcc
+```
+
+#### Using Qt Creator
+Open the Qt Designer project in the Qt folder
+
+#### Using CMake
+Except for the components in the `third_party` folder (e.g., Lua and Duktape), 
CivetWeb can also be built with CMake.
+CMake can be used for all supported operating systems.
+
+
+Building for Linux, BSD, and OSX
+---------
+
+## Using Make
+
+```
+make help
+```
+Get a list of all supported make option
+
+```
+make build
+```
+compile the code
+
+```
+make install
+```
+Install on the system, Linux only.
+
+```
+make lib WITH_CPP=1 WITH_IPV6=1
+make clean slib WITH_CPP=1 WITH_LUA=1 WITH_WEBSOCKET=1
+```
+Build the static and shared libraries.
+The *WITH_CPP* make option is to include the CivetServer class.
+The additional make options configure the library just as it would the 
application.
+
+The *slib* option should be done on a separate clean build as position
+independent code (PIC) is required for it.  Trying to run it after
+building the static library or the server will result in a link error.
+
+```
+make clean
+```
+Clean up files generated during the build
+
+## Setting build options
+
+Make options can be set on the command line with the make command like so.
+```
+make build WITH_LUA=1
+```
+
+
+| Make Options              | Description                               |
+| ------------------------- | ----------------------------------------- |
+| WITH_LUA=1                | build with Lua support                    |
+| WITH_DUKTAPE=1            | build with server-side JavaScript support |
+| WITH_DEBUG=1              | build with GDB debug support              |
+| WITH_IPV6=1               | with IPV6 support                         |
+| WITH_WEBSOCKET=1          | build with web socket support             |
+| WITH_SERVER_STATS=1       | build with support for server statistics  |
+| WITH_CPP=1                | build libraries with c++ classes          |
+| CONFIG_FILE=file          | use 'file' as the config file             |
+| CONFIG_FILE2=file         | use 'file' as the backup config file      |
+| HTMLDIR=/path             | place to install initial web pages        |
+| DOCUMENT_ROOT=/path       | HTMLDIR override, config option, install  |
+|                           | nothing is installed here.                |
+| PORTS=8080                | listening ports override when installing  |
+| SSL_LIB=libssl.so.0       | use versioned SSL library                 |
+| CRYPTO_LIB=libcrypto.so.0 | system versioned CRYPTO library           |
+| PREFIX=/usr/local         | sets the install directory                |
+| COPT='-DNO_SSL'           | method to insert compile flags            |
+
+Note that the WITH_* options used for *make* are not identical to the
+preprocessor defines in the source code - usually USE_* is used there.
+
+## Changing PREFIX
+
+To change the target destination pass the `PREFIX` option to the command `make 
install` (not `make build`). Example usage:
+
+```
+$ make build
+$ make -n install PREFIX=/opt/civetweb
+```
+Note: The `-n` corresponds to the `--dry-run` option (it does not make any 
changes): You can see where `make install` would install. Example output of the 
above command:
+
+```
+$ make -n install PREFIX=/opt/civetweb
+install -d -m 755  "/opt/civetweb/share/doc/civetweb"
+install -m 644 resources/itworks.html 
/opt/civetweb/share/doc/civetweb/index.html
+install -m 644 resources/civetweb_64x64.png /opt/civetweb/share/doc/civetweb/
+install -d -m 755  "/opt/civetweb/etc"
+install -m 644 resources/civetweb.conf  "/opt/civetweb/etc/"
+sed -i 's#^document_root.*$#document_root /opt/civetweb/share/doc/civetweb#' 
"/opt/civetweb/etc/civetweb.conf"
+sed -i 's#^listening_ports.*$#listening_ports 8080#' 
"/opt/civetweb/etc/civetweb.conf"
+install -d -m 755  "/opt/civetweb/share/doc/civetweb"
+install -m 644 *.md "/opt/civetweb/share/doc/civetweb"
+install -d -m 755 "/opt/civetweb/bin"
+install -m 755 civetweb "/opt/civetweb/bin/"
+```
+
+If the output looks good: Just remove the `-n` option to actually install the 
software on your system.
+
+## Setting compile flags
+
+Compile flags can be set using the *COPT* make option like so.
+```
+make build COPT="-DNDEBUG -DNO_CGI"
+```
+
+| Compile Flags             | Description                          |
+| ------------------------- | ------------------------------------ |
+| NDEBUG                    | strip off all debug code             |
+| DEBUG                     | build debug version (very noisy)     |
+| NO_CGI                    | disable CGI support                  |
+| NO_CACHING                | disable caching functionality        |
+| NO_SSL                    | disable SSL functionality            |
+| NO_SSL_DL                 | link against system libssl library   |
+| NO_FILES                  | do not serve files from a directory  |
+| SQLITE_DISABLE_LFS        | disables large files (Lua only)      |
+| SSL_ALREADY_INITIALIZED   | do not initialize libcrypto          |
+
+## Cross Compiling
+
+Take total control with *CC*, *COPT* and *TARGET_OS* as make options.
+TARGET_OS is used to determine some compile details as will as code function.
+TARGET_OS values should be be one found in *resources/Makefile.in-os*.
+
+```
+make CC=arm-none-linux-gnueabi-gcc COPT="-march=armv7-a  -mfpu=vfp 
-mfloat-abi=softfp" TARGET_OS=FROG
+```
+
+## Cocoa DMG Packaging (OSX Only)
+
+Use the alternate *Makefile.osx* to do the build.  The entire build has
+to be done using *Makefile.osx* because additional compile and link options
+are required.  This Makefile has all the same options as the other one plus
+one additional *package* rule.
+
+```
+make -f Makefile.osx package
+```
+
+Building with Buildroot
+---------
+
+[Buildroot](http://buildroot.uclibc.org/) is a tool for creating cross 
compiled file systems.  Including Civetweb in buildroot is fairly easy.  There 
is even support for various build options.
+
+1. First, check if it already there.
+  - In buildroot, make menuconfig
+     - Package Selection for the target --->
+     - Networking applications  --->
+     - civetweb
+2. If not there, just add it
+  - copy *Config.in* and *civetweb.mk* from Civetweb's *contrib/buildroot/* to 
Buildroot's *package/civetweb/* directory.
+  - In Buildroot's *package/Config.in, insert the following line in were you 
will know how to find it in the menu.
+    > ``` source "package/civetweb/Config.in" ```
+
+
+Building on Android
+---------
+
+This is a small guide to help you run civetweb on Android, originally
+tested on the HTC Wildfire.
+Note: You do not need root access to run civetweb on Android.
+
+- Download the source from the Downloads page.
+- Download the Android NDK from 
[http://developer.android.com/tools/sdk/ndk/index.html](http://developer.android.com/tools/sdk/ndk/index.html)
+- Run `/path-to-ndk/ndk-build -C /path-to-civetweb/resources`
+  That should generate civetweb/lib/armeabi/civetweb
+- Using the adb tool (you need to have Android SDK installed for that),
+  push the generated civetweb binary to `/data/local` folder on device.
+- From adb shell, navigate to `/data/local` and execute `./civetweb`.
+- To test if the server is running fine, visit your web-browser and
+  navigate to `http://127.0.0.1:8080` You should see the `Index of /` page.
+
+
+Notes:
+
+- `jni` stands for Java Native Interface. Read up on Android NDK if you want
+  to know how to interact with the native C functions of civetweb in Android
+  Java applications.
+
+
+

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/Contribution.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/Contribution.md 
b/thirdparty/civetweb-1.10/docs/Contribution.md
new file mode 100644
index 0000000..aa88c14
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/Contribution.md
@@ -0,0 +1,23 @@
+Contributing to CivetWeb
+====
+
+Contributions to CivetWeb are welcome, provided all contributions carry the 
MIT license.
+
+- Please report issues on GitHub. If the issue you want to report is already 
reported there, add a note with your specific details to that issue. In case of 
doubt, please create a new issue.
+- If you know how to fix the issue, please create a pull request on GitHub. 
Please take care your modifications pass the continuous integration checks. 
These checks are performed automatically when you create a pull request, but it 
may take some hours until all tests are completed. Please provide a description 
for every pull request.
+- Alternatively, you can post a patch or describe the required modifications 
in a GitHub issue.
+However, a pull request would be preferred.
+- Contributor names are listed in CREDITS.md, unless you explicitly state you 
don't want your name to be listed there. This file is occasionally updated, 
adding new contributors, using author names from git commits and GitHub 
comments.
+
+
+- In case your modifications either
+  1. modify or extend the API,
+  2. affect multi-threading,
+  3. imply structural changes,
+  or
+  4. have significant influence on maintenance,
+  
+  please first create an issue on GitHub or create a thread on the CivetWeb 
discussion group, to discuss the planned changed.
+
+- In case you think you found a security issue that should be evaluated and 
fixed before public disclosure, feel free to write an email.  Although CivetWeb 
is a fork from Mongoose from 2013, the code bases are different now, so 
security vulnerabilities of Mongoose usually do not affect CivetWeb.  Open an 
issue for Mongoose vulnerabilities you want to have checked if CivetWeb is 
affected.
+

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/Embedding.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/Embedding.md 
b/thirdparty/civetweb-1.10/docs/Embedding.md
new file mode 100644
index 0000000..0ffbc23
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/Embedding.md
@@ -0,0 +1,260 @@
+Embedding CivetWeb
+=========
+
+CivetWeb is primarily designed so applications can easily add HTTP and HTTPS 
server as well as WebSocket functionality.  For example, an application server 
could use CivetWeb to enable a web service interface for automation or remote 
control.
+
+However, it can also be used as a stand-alone executable. It can deliver 
static files and offers built-in server side Lua, JavaScript and CGI support. 
Some instructions how to build the stand-alone server can be found in 
[Building.md](https://github.com/civetweb/civetweb/blob/master/docs/Building.md).
+
+Files
+------
+
+There is just a small set of files to compile in to the application,
+but if a library is desired, see 
[Building.md](https://github.com/CivetWeb/CivetWeb/blob/master/docs/Building.md)
+
+#### Regarding the INL file extension
+The *INL* file extension represents code that is statically included inline in 
a source file.  Slightly different from C++ where it means "inline" code which 
is technically not the same as static code. CivetWeb overloads this extension 
for the sake of clarity as opposed to having .c extensions on files that should 
not be directly compiled.
+
+#### HTTP Server Source Files
+
+These files constitute the CivetWeb library.  They do not contain a `main` 
function,
+but all functions required to run a HTTP server.
+
+  - HTTP server API
+    - include/civetweb.h
+  - C implementation
+    - src/civetweb.c
+    - src/md5.inl (MD5 calculation)
+    - src/sha1.inl (SHA calculation)
+    - src/handle\_form.inl (HTML form handling functions)
+    - src/timer.inl (optional timer support)
+  - Optional: C++ wrapper
+    - include/CivetServer.h (C++ interface)
+    - src/CivetServer.cpp (C++ wrapper implementation)
+  - Optional: Third party components
+    - src/third\_party/* (third party components, mainly used for the 
standalone server)
+    - src/mod\_*.inl (modules to access third party components from civetweb)
+
+
+Note: The C++ wrapper uses the official C interface (civetweb.h) and does not 
add new features to the server. Several features available in the C interface 
are missing in the C++ interface. While all features should be accessible using 
the C interface, this is not a design goal of the C++ interface.
+
+
+#### Additional Source Files for Executables
+
+These files can be used to build a server executable. They contain a `main` 
function
+starting the HTTP server.
+
+  - Stand-alone C Server
+      - src/main.c
+  - Reference embedded C Server
+      - examples/embedded\_c/embedded\_c.c
+  - Reference embedded C++ Server
+      - examples/embedded\_cpp/embedded\_cpp.cpp
+
+Note: The "embedded" example is actively maintained, updated, extended and 
tested. Other examples in the examples/ folder might be outdated and remain 
there for reference.
+
+
+Quick Start
+------
+
+By default, the server will automatically serve up files like a normal HTTP 
server.  An embedded server is most likely going to overload this functionality.
+
+### C
+  - Include the C interface ```civetweb.h```.
+  - Use `mg_start()` to start the server.
+      - Use *options* to select the port and document root among other things.
+      - Use *callbacks* to add your own hooks.
+  - Use `mg_set_request_handler()` to easily add your own request handlers.
+  - Use `mg_stop()` to stop the server.
+
+### C++
+  - Note that CivetWeb is Clean C, and C++ interface ```CivetServer.h``` is 
only a wrapper layer around the C interface.
+    Not all CivetWeb features available in C are also available in C++.
+  - Create CivetHandlers for each URI.
+  - Register the handlers with `CivetServer::addHandler()`
+  - `CivetServer` starts on contruction and stops on destruction.
+  - Use contructor *options* to select the port and document root among other 
things.
+  - Use constructor *callbacks* to add your own hooks.
+
+Alternative quick start: Have a look at the examples embedded\_c and 
embedded\_cpp
+
+
+Lua Support
+------
+
+Lua is a server side include functionality.  Files ending in .lua will be 
processed with Lua.
+
+##### Add the following CFLAGS
+
+  - `-DLUA_COMPAT_ALL`
+  - `-DUSE_LUA`
+  - `-DUSE_LUA_SQLITE3`
+  - `-DUSE_LUA_FILE_SYSTEM`
+
+##### Add the following sources
+
+  - src/mod\_lua.inl
+  - src/third\_party/lua-5.2.4/src
+     + lapi.c
+     + lauxlib.c
+     + lbaselib.c
+     + lbitlib.c
+     + lcode.c
+     + lcorolib.c
+     + lctype.c
+     + ldblib.c
+     + ldebug.c
+     + ldo.c
+     + ldump.c
+     + lfunc.c
+     + lgc.c
+     + linit.c
+     + liolib.c
+     + llex.c
+     + lmathlib.c
+     + lmem.c
+     + loadlib.c
+     + lobject.c
+     + lopcodes.c
+     + loslib.c
+     + lparser.c
+     + lstate.c
+     + lstring.c
+     + lstrlib.c
+     + ltable.c
+     + ltablib.c
+     + ltm.c
+     + lundump.c
+     + lvm.c
+     + lzio.c
+  - src/third\_party/sqlite3.c
+  - src/third\_party/sqlite3.h
+  - src/third\_party/lsqlite3.c
+  - src/third\_party/lfs.c
+  - src/third\_party/lfs.h
+
+This build is valid for Lua version Lua 5.2. It is also possible to build with 
Lua 5.1 (including LuaJIT) or Lua 5.3.
+
+
+JavaScript Support
+------
+
+CivetWeb can be built with server side JavaScript support by including the 
Duktape library.
+
+
+CivetWeb internals
+------
+
+CivetWeb is multithreaded web server. `mg_start()` function allocates
+web server context (`struct mg_context`), which holds all information
+about web server instance:
+
+- configuration options. Note that CivetWeb makes internal copies of
+  passed options.
+- SSL context, if any
+- user-defined callbacks
+- opened listening sockets
+- a queue for accepted sockets
+- mutexes and condition variables for inter-thread synchronization
+
+When `mg_start()` returns, all initialization is guaranteed to be complete
+(e.g. listening ports are opened, SSL is initialized, etc). `mg_start()` starts
+some threads: a master thread, that accepts new connections, and several
+worker threads, that process accepted connections. The number of worker threads
+is configurable via `num_threads` configuration option. That number puts a
+limit on number of simultaneous requests that can be handled by CivetWeb.
+If you embed CivetWeb into a program that uses SSL outside CivetWeb as well,
+you may need to initialize SSL before calling `mg_start()`, and set the pre-
+processor define `SSL_ALREADY_INITIALIZED`. This is not required if SSL is
+used only within CivetWeb.
+
+When master thread accepts new a connection, a new accepted socket (described
+by `struct socket`) it placed into the accepted sockets queue,
+which has size of `MGSQLEN` (default 20).
+Any idle worker thread can grab accepted sockets from that queue.
+If all worker threads are busy, master thread can accept and queue up to
+20 more TCP connections, filling up the queue.
+In the attempt to queue even more accepted connection, the master thread blocks
+until there is space in the queue. When the master thread is blocked on a
+full queue, the operating system can also queue incoming connection.
+The number is limited by the `listen()` call parameter,
+which is `SOMAXCONN` and depends on the platform.
+
+Worker threads are running in an infinite loop, which in a simplified form
+looks something like this:
+
+```C
+    static void *worker_thread() {
+      while (consume_socket()) {
+        process_new_connection();
+      }
+    }
+```
+
+Function `consume_socket()` gets a new accepted socket from the CivetWeb socket
+queue, atomically removing it from the queue. If the queue is empty,
+`consume_socket()` blocks and waits until a new socket is placed in the queue
+by the master thread.
+
+`process_new_connection()` actually processes the
+connection, i.e. reads the request, parses it, and performs appropriate action
+depending on the parsed request.
+
+Master thread uses `poll()` and `accept()` to accept new connections on
+listening sockets. `poll()` is used to avoid `FD_SETSIZE` limitation of
+`select()`. Since there are only a few listening sockets, there is no reason
+to use hi-performance alternatives like `epoll()` or `kqueue()`. Worker
+threads use blocking IO on accepted sockets for reading and writing data.
+All accepted sockets have `SO_RCVTIMEO` and `SO_SNDTIMEO` socket options set
+(controlled by the `request_timeout_ms` CivetWeb option, 30 seconds default)
+which specifies a read/write timeout on client connections.
+
+
+A minimal example
+------
+
+Initializing a HTTP server
+```C
+{
+    /* Server context handle */
+    struct mg_context *ctx;
+
+    /* Initialize the library */
+    mg_init_library(0);
+
+    /* Start the server */
+    ctx = mg_start(NULL, 0, NULL);
+
+    /* Add some handler */
+    mg_set_request_handler(ctx, "/hello", handler, "Hello world");
+
+    ... Run the application ...
+    
+    /* Stop the server */
+    mg_stop(ctx);
+
+    /* Un-initialize the library */
+    mg_exit_library();
+}
+```
+
+A simple callback
+```C
+static int
+handler(struct mg_connection *conn, void *ignored)
+{
+       const char *msg = "Hello world";
+       unsigned long len = (unsigned long)strlen(msg);
+
+       mg_printf(conn,
+                 "HTTP/1.1 200 OK\r\n"
+                 "Content-Length: %lu\r\n"
+                 "Content-Type: text/plain\r\n"
+                 "Connection: close\r\n\r\n",
+                 len);
+
+       mg_write(conn, msg, len);
+
+       return 200;
+}
+```
+

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/Installing.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/Installing.md 
b/thirdparty/civetweb-1.10/docs/Installing.md
new file mode 100644
index 0000000..2476b94
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/Installing.md
@@ -0,0 +1,38 @@
+Civetweb Install Guide
+====
+
+This guide covers the distributions for CivetWeb.  The latest source code is 
available at 
[https://github.com/civetweb/civetweb](https://github.com/civetweb/civetweb).
+
+Windows
+---
+
+This pre-built version comes pre-built wit Lua support. Libraries for SSL 
support are not included due to licensing restrictions;
+however, users may add an SSL library themselves.
+Instructions for adding SSL support can be found in 
[https://github.com/civetweb/civetweb/tree/master/docs](https://github.com/civetweb/civetweb/tree/master/docs)
+
+1. In case the Visual C++ Redistributable are not already installed:
+  32 Bit Version: Install the [Redistributable for Visual Studio 
2010](http://www.microsoft.com/en-us/download/details.aspx?id=8328)
+  64 Bit Version: Install the [Redistributable for Visual Studio 
2015](http://www.microsoft.com/en-us/download/details.aspx?id=48145)
+  Note: The required version of the Redistributables may vary, depending on 
the CivetWeb version.
+2. Download latest *civetweb-win.zip* from 
[SourceForge](https://sourceforge.net/projects/civetweb/files/)
+3. When started, Civetweb puts itself into the tray.
+
+OS X
+---
+
+This pre-built version comes with Lua, IPV6 and SSL support.
+
+1. Download the latest *Civetweb.dmg* from 
[SourceForge](https://sourceforge.net/projects/civetweb/files/)
+2. Click on the it and look for the attachment in the finder.
+4. Drag Civetweb to the Applications folder.
+5. When started, Civetweb puts itself into top menu.
+
+Linux
+---
+
+1. Download the latest *civetweb.tar.gz* from 
[SourceForge](https://sourceforge.net/projects/civetweb/files/)
+2. Open archive and change to the new directory.
+3. make help
+4. make
+5. make install
+6. Run the program ```/usr/local/bin/civetweb```, it will use the 
configuration file */usr/local/etc/civetweb.conf*.

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/Interface_Changes_1.10.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/Interface_Changes_1.10.md 
b/thirdparty/civetweb-1.10/docs/Interface_Changes_1.10.md
new file mode 100644
index 0000000..16bc7dd
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/Interface_Changes_1.10.md
@@ -0,0 +1,86 @@
+# Interface changes
+
+## Proposed interface changes for 1.10
+
+Status: To be discussed
+
+### Server interface
+
+#### mg\_start / mg\_init\_library
+
+Calling mg\_init\_library is recommended before calling mg\_start.
+
+Compatibility:
+Initially, mg\_init\_library will be called implicitly if it has 
+not been called before mg\_start.
+If mg\_init\_library was not called, mg\_stop may leave memory leaks.
+
+#### mg\_websocket\_write functions
+
+Calling mg\_lock\_connection is no longer called implicitly
+in mg\_websocket\_write functions. 
+If you use websocket write functions them from two threads,
+you must call mg\_lock\_connection explicitly, just like for any
+other connection.
+
+This is an API harmonization issue.
+
+Compatibility:
+If a websocket connection was used in only one thread, there is
+no incompatibility. If a websocket connection was used in multiple
+threads, the user has to add the mg\_lock\_connection before and
+the mg\_unlock\_connection after the websocket write call.
+
+#### open\_file member of mg\_callbacks
+
+This member is going to be removed.
+It is superseeded by mg\_add\_request\_handler.
+
+Compatibility:
+Current code using open\_file needs to be changed.
+Instructions how to do this will be provided.
+
+
+### Client interface
+
+
+#### mg\_init\_library
+
+Calling mg\_init\_library is required before calling any client
+function. In particular, the TLS initialization must be done
+before using mg\_connect\_client\_secure.
+
+Compatibility:
+Some parts of the client interface did not work, if mg\_start
+was not called before. Now server and client become independent.
+
+#### mg\_connect\_client (family)
+
+mg_connect_client needs several new parameters (options).
+
+Details are to be defined.
+
+mg_connect_client and mg_download should return a different kind of
+mg_connection than used in server callbacks. At least, there should
+be a function mg_get_response_info, instead of using 
+mg_get_request_info, and getting the HTTP response code from the
+server by looking into the uri member of struct mg_request_info.
+
+
+### `size_t` in all interface
+
+Having `size_t` in interfaces while building for 32 and 64 bit
+complicates maintenance in an unnecessary way 
+(see [498](https://github.com/civetweb/civetweb/issues/498)).
+
+Replace all data sizes by 64 bit integers.
+
+
+### Pattern definition
+
+The current definition of pattern matching is problematic
+(see [499](https://github.com/civetweb/civetweb/issues/499)).
+
+Find and implement a new definition.
+
+

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/OpenSSL.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/OpenSSL.md 
b/thirdparty/civetweb-1.10/docs/OpenSSL.md
new file mode 100644
index 0000000..1f01cca
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/OpenSSL.md
@@ -0,0 +1,153 @@
+Adding OpenSSL Support
+=====
+
+Civetweb supports *HTTPS* connections using the OpenSSL transport layer
+security (TLS) library. OpenSSL is a free, open source library (see
+http://www.openssl.org/).
+
+
+Getting Started
+----
+
+- Install OpenSSL on your system. There are OpenSSL install packages for all
+  major Linux distributions as well as a setup for Windows.
+- The default build configuration of the civetweb web server will load the
+  required OpenSSL libraries, if a HTTPS certificate has been configured.
+
+
+Civetweb Configuration
+----
+
+The configuration file must contain an https port, identified by a letter 's'
+attached to the port number.
+To serve http and https from their standard ports use the following line in
+the configuration file 'civetweb.conf':
+<pre>
+  listening_ports 80, 443s
+</pre>
+To serve only https use:
+<pre>
+  listening_ports 443s
+</pre>
+
+Furthermore the SSL certificate file must be set:
+<pre>
+  ssl_certificate d:\civetweb\certificate\server.pem
+</pre>
+
+
+Creating a self signed certificate
+----
+
+OpenSSL provides a command line interface, that can be used to create the
+certificate file required by civetweb (server.pem).
+
+One can use the following steps in Windows (in Linux replace "copy" by "cp"
+and "type" by "cat"):
+
+<pre>
+  openssl genrsa -des3 -out server.key 1024
+
+  openssl req -new -key server.key -out server.csr
+
+  copy server.key server.key.orig
+
+  openssl rsa -in server.key.orig -out server.key
+
+  openssl x509 -req -days 3650 -in server.csr -signkey server.key -out 
server.crt
+
+  copy server.crt server.pem
+
+  type server.key >> server.pem
+</pre>
+
+The server.pem file created must contain a 'CERTIFICATE' section as well as a
+'RSA PRIVATE KEY' section. It should look like this (x represents BASE64
+encoded data):
+
+<pre>
+-----BEGIN CERTIFICATE-----
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxx
+-----END CERTIFICATE-----
+-----BEGIN RSA PRIVATE KEY-----
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+-----END RSA PRIVATE KEY-----
+</pre>
+
+
+Including a certificate from a certificate authority
+----
+
+CivetWeb requires one certificate file in PEM format.
+If you got multiple files from your certificate authority,
+you need to copy their content together into one file.
+Make sure the file has one section BEGIN RSA PRIVATE KEY /
+END RSA PRIVATE KEY, and at least one section
+BEGIN CERTIFICATE / END CERTIFICATE.
+In case you received a file with a section
+BEGIN PRIVATE KEY / END PRIVATE KEY,
+you may get a suitable file by adding the letters RSA manually.
+
+Set the "ssl_certificate" configuration parameter to the
+file name (including path) of the resulting *.pem file.
+
+The file must look like the file in the section
+"Creating a self signed certificate", but it will have several
+BEGIN CERTIFICATE / END CERTIFICATE sections.
+
+
+Common Problems
+----
+
+In case the OpenSSL configuration is not set up correctly, the server will not
+start. Configure an error log file in 'civetweb.conf' to get more information:
+<pre>
+  error_log_file error.log
+</pre>
+
+Check the content of 'error.log':
+
+<pre>
+load_dll: cannot load libeay32.*/libcrypto.*/ssleay32.*/libssl.*
+</pre>
+This error message means, the SSL library has not been installed (correctly).
+For Windows you might use the pre-built binaries. A link is available at the
+OpenSSL project home page (http://www.openssl.org/related/binaries.html).
+Choose the windows system folder as installation directory - this is the
+default location.
+
+<pre>
+set_ssl_option: cannot open server.pem: error:PEM routines:*:PEM_read_bio:no 
start line
+set_ssl_option: cannot open server.pem: error:PEM routines:*:PEM_read_bio:bad 
end line
+</pre>
+These error messages indicate, that the format of the ssl_certificate file does
+not match the expectations of the SSL library. The PEM file must contain both,
+a 'CERTIFICATE' and a 'RSA PRIVATE KEY' section. It should be a strict ASCII
+file without byte-order marks.
+The instructions above may be used to create a valid ssl_certificate file.
+
+

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/README.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/README.md 
b/thirdparty/civetweb-1.10/docs/README.md
new file mode 100644
index 0000000..9494409
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/README.md
@@ -0,0 +1,42 @@
+![CivetWeb](https://raw.github.com/civetweb/civetweb/master/resources/civetweb_64x64.png
 "CivetWeb") CivetWeb
+=======
+
+CivetWeb is an easy to use, powerful, C/C++ embeddable web server with 
optional CGI, SSL and Lua support.
+
+CivetWeb can be used by developers as a library, to add web server 
functionality to an existing application.
+CivetWeb uses an [MIT 
license](https://github.com/civetweb/civetweb/blob/master/LICENSE.md).
+
+It can also be used by end users as a stand-alone web server. It is available 
as single executable, no installation is required.
+
+The current stable version is 1.9.1 - [release 
notes](https://github.com/civetweb/civetweb/blob/master/RELEASE_NOTES.md)
+
+
+End users can download CivetWeb at SourceForge
+[https://sourceforge.net/projects/civetweb/](https://sourceforge.net/projects/civetweb/)
+
+Developers can contribute to CivetWeb via GitHub
+[https://github.com/civetweb/civetweb](https://github.com/civetweb/civetweb)
+
+Trouble tickets should be filed on GitHub
+[https://github.com/civetweb/civetweb/issues](https://github.com/civetweb/civetweb/issues)
+
+Announcements are at Google Groups
+[https://groups.google.com/d/forum/civetweb](https://groups.google.com/d/forum/civetweb)
+
+While older support question and discussion threads have been at [Google 
groups](https://groups.google.com/d/forum/civetweb), most newer ones are 
[GitHub issues](https://github.com/civetweb/civetweb/issues).
+
+Source releases can be found on GitHub
+[https://github.com/civetweb/civetweb/releases](https://github.com/civetweb/civetweb/releases)
+
+
+Documentation
+---------------
+
+- [Installing.md](Installing.md) - Install Guide (for end users using 
pre-built binaries)
+- [UserManual.md](UserManual.md) - End User Guide
+- [Building.md](Building.md) - Building the Server (quick start guide)
+- [Embedding.md](Embedding.md) - Embedding (how to add HTTP support to an 
existing application)
+- [OpenSSL.md](OpenSSL.md) - Adding HTTPS (SSL/TLS) support using OpenSSL.
+- [API documentation](api) - Additional documentation on the civetweb 
application programming interface 
([civetweb.h](https://github.com/civetweb/civetweb/blob/master/include/civetweb.h)).
+
+[Authors](https://github.com/civetweb/civetweb/blob/master/CREDITS.md)

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/UserManual.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/UserManual.md 
b/thirdparty/civetweb-1.10/docs/UserManual.md
new file mode 100644
index 0000000..3acf492
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/UserManual.md
@@ -0,0 +1,814 @@
+
+Overview
+=====
+
+Civetweb is small and easy to use web server.
+It may be embedded into C/C++ host applications or used as a stand-alone
+server. See `Embedding.md` for information on embedding civetweb into
+host applications.
+
+The stand-alone server is self-contained, and does not require any external
+software to run. Some Windows users may need to install the
+[Visual C++ 
Redistributable](http://www.microsoft.com/en-us/download/details.aspx?id=30679).
+
+Installation
+----
+
+On Windows, UNIX and Mac, the civetweb stand-alone executable may be started
+from the command line.
+Running `civetweb` in a terminal, optionally followed by configuration 
parameters
+(`civetweb [OPTIONS]`) or a configuration file name (`civetweb 
[config_file_name]`),
+starts the web server.
+
+For UNIX and Mac, civetweb does not detach from the terminal.
+Pressing `Ctrl-C` keys will stop the server.
+
+On Windows, civetweb iconifies itself to the system tray icon when started.
+Right-click on the icon pops up a menu, where it is possible to stop
+civetweb, or configure it, or install it as Windows service.
+
+When started without options, the server exposes the local directory at
+[http](http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) port 8080.
+Thus, the easiest way to share a folder on Windows is to copy `civetweb.exe`
+to this folder, double-click the exe, and launch a browser at
+[http://localhost:8080](http://localhost:8080). Note that 'localhost' should
+be changed to a machine's name if a folder is accessed from other computer.
+
+When started, civetweb first searches for the configuration file.
+If configuration file is specified explicitly in the command line, i.e.
+`civetweb path_to_config_file`, then specified configuration file is used.
+Otherwise, civetweb would search for file `civetweb.conf` in the same directory
+the executable is located, and use it. This configuration file is optional.
+
+The configuration file is a sequence of lines, each line containing one
+command line argument name and the corresponding value.
+Empty lines, and lines beginning with `#`, are ignored.
+Here is the example of `civetweb.conf` file:
+
+    document_root c:\www
+    listening_ports 80,443s
+    ssl_certificate c:\civetweb\ssl_cert.pem
+
+When a configuration file is used, additional command line arguments may
+override the configuration file settings.
+All command line arguments must start with `-`.
+
+For example: The above `civetweb.conf` file is used, and civetweb started as
+`civetweb -document_root D:\web`. Then the `D:\web` directory will be served
+as document root, because command line options take priority over the
+configuration file. The configuration options section below provides a good
+overview of the Civetweb features.
+
+Note that configuration options on the command line must start with `-`,
+but their names are the same as in the config file. All option names are
+listed in the next section. Thus, the following two setups are equivalent:
+
+    # Using command line arguments
+    $ civetweb -listening_ports 1234 -document_root /var/www
+
+    # Using config file
+    $ cat civetweb.conf
+    listening_ports 1234
+    document_root /var/www
+    $ civetweb
+
+Civetweb can also be used to modify `.htpasswd` passwords files:
+
+    civetweb -A <htpasswd_file> <realm> <user> <passwd>
+
+Unlike other web servers, civetweb does not require CGI scripts to be located
+in a special directory. CGI scripts can be anywhere. CGI (and SSI) files are
+recognized by the file name pattern. Civetweb uses shell-like glob
+patterns. Pattern match starts at the beginning of the string, so essentially
+patterns are prefix patterns. Syntax is as follows:
+
+     **      Matches everything
+     *       Matches everything but slash character, '/'
+     ?       Matches any character
+     $       Matches the end of the string
+     |       Matches if pattern on the left side or the right side matches.
+
+All other characters in the pattern match themselves. Examples:
+
+    **.cgi$      Any string that ends with .cgi
+    /foo         Any string that begins with /foo
+    **a$|**b$    Any string that ends with a or b
+
+# Configuration Options
+
+Below is a list of configuration options understood by Civetweb.
+Every option is followed by it's default value. If a default value is not
+present, then the default is empty.
+
+### cgi\_pattern `**.cgi$|**.pl$|**.php$`
+All files that match `cgi_pattern` are treated as CGI files. Default pattern
+allows CGI files be anywhere. To restrict CGIs to a certain directory,
+use `/path/to/cgi-bin/**.cgi` as pattern. Note that the full file path is
+matched against the pattern, not the URI.
+
+### cgi\_environment
+Extra environment variables to be passed to the CGI script in
+addition to standard ones. The list must be comma-separated list
+of name=value pairs, like this: `VARIABLE1=VALUE1,VARIABLE2=VALUE2`.
+
+### put\_delete\_auth\_file
+Passwords file for PUT and DELETE requests. Without password file, it will not
+be possible to, PUT new files to the server or DELETE existing ones. PUT and
+DELETE requests might still be handled by Lua scripts and CGI paged.
+
+### cgi\_interpreter
+Path to an executable to use as CGI interpreter for __all__ CGI scripts
+regardless of the script file extension. If this option is not set (which is
+the default), Civetweb looks at first line of a CGI script,
+[shebang line](http://en.wikipedia.org/wiki/Shebang_(Unix\)), for an
+interpreter (not only on Linux and Mac but also for Windows).
+
+For example, if both PHP and Perl CGIs are used, then
+`#!/path/to/php-cgi.exe` and `#!/path/to/perl.exe` must be first lines of the
+respective CGI scripts. Note that paths should be either full file paths,
+or file paths relative to the current working directory of the civetweb
+server. If civetweb is started by mouse double-click on Windows, the current
+working directory is the directory where the civetweb executable is located.
+
+If all CGIs use the same interpreter, for example they are all PHP, it is
+more efficient to set `cgi_interpreter` to the path to `php-cgi.exe`.
+The  shebang line in the CGI scripts can be omitted in this case.
+Note that PHP scripts must use `php-cgi.exe` as executable, not `php.exe`.
+
+### protect\_uri
+Comma separated list of URI=PATH pairs, specifying that given
+URIs must be protected with password files specified by PATH.
+All Paths must be full file paths.
+
+### authentication\_domain `mydomain.com`
+Authorization realm used for HTTP digest authentication. This domain is
+used in the encoding of the `.htpasswd` authorization files as well.
+Changing the domain retroactively will render the existing passwords useless.
+
+### enable\_auth\_domain\_check `yes`
+When using absolute URLs, verify the host is identical to the 
authentication\_domain. If enabled, requests to absolute URLs will only be 
processed 
+if they are directed to the domain. If disabled, absolute URLs to any host
+will be accepted.
+
+### ssi\_pattern `**.shtml$|**.shtm$`
+All files that match `ssi_pattern` are treated as Server Side Includes (SSI).
+
+SSI is a simple interpreted server-side scripting language which is most
+commonly used to include the contents of another file into a web page.
+It can be useful when it is desirable to include a common piece
+of code throughout a website, for example, headers and footers.
+
+In order for a webpage to recognize an SSI-enabled HTML file, the filename
+should end with a special extension, by default the extension should be
+either `.shtml` or `.shtm`. These extentions may be changed using the
+`ssi_pattern` option.
+
+Unknown SSI directives are silently ignored by civetweb. Currently, two SSI
+directives are supported, `<!--#include ...>` and
+`<!--#exec "command">`. Note that the `<!--#include ...>` directive supports
+three path specifications:
+
+    <!--#include virtual="path">  Path is relative to web server root
+    <!--#include abspath="path">  Path is absolute or relative to
+                                  web server working dir
+    <!--#include file="path">,    Path is relative to current document
+    <!--#include "path">
+
+The `include` directive may be used to include the contents of a file or the
+result of running a CGI script. The `exec` directive is used to execute a
+command on a server, and show the output that would have been printed to
+stdout (the terminal window) otherwise. Example:
+
+    <!--#exec "ls -l" -->
+
+For more information on Server Side Includes, take a look at the Wikipedia:
+[Server Side Includes](http://en.wikipedia.org/wiki/Server_Side_Includes)
+
+### throttle
+Limit download speed for clients.  `throttle` is a comma-separated
+list of key=value pairs, where key could be:
+
+    *                   limit speed for all connections
+    x.x.x.x/mask        limit speed for specified subnet
+    uri_prefix_pattern  limit speed for given URIs
+
+The value is a floating-point number of bytes per second, optionally
+followed by a `k` or `m` character, meaning kilobytes and
+megabytes respectively. A limit of 0 means unlimited rate. The
+last matching rule wins. Examples:
+
+    *=1k,10.0.0.0/8=0   limit all accesses to 1 kilobyte per second,
+                        but give connections the from 10.0.0.0/8 subnet
+                        unlimited speed
+
+    /downloads/=5k      limit accesses to all URIs in `/downloads/` to
+                        5 kilobytes per second. All other accesses are 
unlimited
+
+### access\_log\_file
+Path to a file for access logs. Either full path, or relative to the current
+working directory. If absent (default), then accesses are not logged.
+
+### enable\_directory\_listing `yes`
+Enable directory listing, either `yes` or `no`.
+
+### error\_log\_file
+Path to a file for error logs. Either full path, or relative to the current
+working directory. If absent (default), then errors are not logged.
+
+### global\_auth\_file
+Path to a global passwords file, either full path or relative to the current
+working directory. If set, per-directory `.htpasswd` files are ignored,
+and all requests are authorized against that file.
+
+The file has to include the realm set through `authentication_domain` and the
+password in digest format:
+
+    user:realm:digest
+    test:test.com:ce0220efc2dd2fad6185e1f1af5a4327
+
+Password files may be generated using `civetweb -A` as explained above, or
+online tools e.g. [this 
generator](http://www.askapache.com/online-tools/htpasswd-generator).
+
+### index\_files 
`index.xhtml,index.html,index.htm,index.cgi,index.shtml,index.php`
+Comma-separated list of files to be treated as directory index files.
+If more than one matching file is present in a directory, the one listed to 
the left
+is used as a directory index.
+
+In case built-in Lua support has been enabled, `index.lp,index.lsp,index.lua`
+are additional default index files, ordered before `index.cgi`.
+
+### enable\_keep\_alive `no`
+Enable connection keep alive, either `yes` or `no`.
+
+Allows clients to reuse TCP connection for subsequent HTTP requests, 
+which improves performance.
+For this to work when using request handlers it is important to add the
+correct Content-Length HTTP header for each request. If this is forgotten the
+client will time out.
+
+Note: If you set keep\_alive to `yes`, you should set keep\_alive\_timeout\_ms
+to some value > 0 (e.g. 500). If you set keep\_alive to `no`, you should set
+keep\_alive\_timeout\_ms to 0. Currently, this is done as a default value,
+but this configuration is redundant. In a future version, the keep\_alive 
+configuration option might be removed and automatically set to `yes` if 
+a timeout > 0 is set.
+
+### access\_control\_list
+An Access Control List (ACL) allows restrictions to be put on the list of IP
+addresses which have access to the web server. In the case of the Civetweb
+web server, the ACL is a comma separated list of IP subnets, where each
+subnet is pre-pended by either a `-` or a `+` sign. A plus sign means allow,
+where a minus sign means deny. If a subnet mask is omitted, such as `-1.2.3.4`,
+this means to deny only that single IP address.
+
+Subnet masks may vary from 0 to 32, inclusive. The default setting is to allow
+all accesses. On each request the full list is traversed, and
+the last match wins. Examples:
+
+    -0.0.0.0/0,+192.168/16    deny all accesses, only allow 192.168/16 subnet
+
+To learn more about subnet masks, see the
+[Wikipedia page on Subnetwork](http://en.wikipedia.org/wiki/Subnetwork).
+
+### extra\_mime\_types
+Extra mime types, in tha form `extension1=type1,exten-sion2=type2,...`.
+See the [Wikipedia page on Internet media 
types](http://en.wikipedia.org/wiki/Internet_media_type).
+Extension must include a leading dot. Example:
+`.cpp=plain/text,.java=plain/text`
+
+### listening\_ports `8080`
+Comma-separated list of ports to listen on. If the port is SSL, a
+letter `s` must be appended, for example, `80,443s` will open
+port 80 and port 443, and connections on port 443 will be SSL-ed.
+For non-SSL ports, it is allowed to append letter `r`, meaning 'redirect'.
+Redirect ports will redirect all their traffic to the first configured
+SSL port. For example, if `listening_ports` is `80r,443s`, then all
+HTTP traffic coming at port 80 will be redirected to HTTPS port 443.
+
+It is possible to specify an IP address to bind to. In this case,
+an IP address and a colon must be pre-pended to the port number.
+For example, to bind to a loopback interface on port 80 and to
+all interfaces on HTTPS port 443, use `127.0.0.1:80,443s`.
+
+If the server is built with IPv6 support, `[::]:8080` can be used to
+listen to IPv6 connections to port 8080. IPv6 addresses of network
+interfaces can be specified as well,
+e.g. `[::1]:8080` for the IPv6 loopback interface.
+
+[::]:80 will bind to port 80 IPv6 only. In order to use port 80 for
+all interfaces, both IPv4 and IPv6, use either the configuration
+`80,[::]:80` (create one socket for IPv4 and one for IPv6 only),
+or `+80` (create one socket for both, IPv4 and IPv6). 
+The `+`-notation to use IPv4 and IPv6 will only work in no network
+interface is specified. Depending on your operating system version
+and IPv6 network environment, some configurations might not work
+as expected, so you have to test to find the configuration most 
+suitable for your needs. In case `+80` does not work for your
+environment, you need to use `80,[::]:80`.
+
+It is possible to use network interface addresses (e.g., `192.0.2.3:80`,
+`[2001:0db8::1234]:80`). To get a list of available network interface
+addresses, use `ipconfig` (in a `cmd` window in Windows) or `ifconfig` 
+(in a Linux shell).
+Alternatively, you could use the hostname for an interface. Check the 
+hosts file of your operating system for a proper hostname 
+(for Windows, usually found in C:\Windows\System32\drivers\etc\, 
+for most Linux distributions: /etc/hosts). E.g., to bind the IPv6 
+local host, you could use `ip6-localhost:80`. This translates to 
+`[::1]:80`. Beside the hosts file, there are several other name
+resolution services. Using your hostname might bind you to the
+localhost or an external interface. You could also try `hostname.local`,
+if the proper network services are installed (Zeroconf, mDNS, Bonjour, 
+Avahi). When using a hostname, you need to test in your particular network
+environment - in some cases, you might need to resort to a fixed IP address.
+
+### document\_root `.`
+A directory to serve. By default, the current working directory is served.
+The current directory is commonly referenced as dot (`.`).
+It is recommended to use an absolute path for document\_root, in order to 
+avoid accidentally serving the wrong directory.
+
+### ssl\_certificate
+Path to the SSL certificate file. This option is only required when at least
+one of the `listening\_ports` is SSL. The file must be in PEM format,
+and it must have both, private key and certificate, see for example
+[ssl_cert.pem](https://github.com/civetweb/civetweb/blob/master/resources/ssl_cert.pem)
+A description how to create a certificate can be found in doc/OpenSSL.md
+
+### num\_threads `50`
+Number of worker threads. Civetweb handles each incoming connection in a
+separate thread. Therefore, the value of this option is effectively the number
+of concurrent HTTP connections Civetweb can handle.
+
+### run\_as\_user
+Switch to given user credentials after startup. Usually, this option is
+required when civetweb needs to bind on privileged ports on UNIX. To do
+that, civetweb needs to be started as root. From a security point of view,
+running as root is not advisable, therefore this option can be used to drop
+privileges. Example:
+
+    civetweb -listening_ports 80 -run_as_user webserver
+
+### url\_rewrite\_patterns
+Comma-separated list of URL rewrites in the form of
+`uri_pattern=file_or_directory_path`. When Civetweb receives any request,
+it constructs the file name to show by combining `document_root` and the URI.
+However, if the rewrite option is used and `uri_pattern` matches the
+requested URI, then `document_root` is ignored. Instead,
+`file_or_directory_path` is used, which should be a full path name or
+a path relative to the web server's current working directory. Note that
+`uri_pattern`, as all civetweb patterns, is a prefix pattern.
+
+This makes it possible to serve many directories outside from `document_root`,
+redirect all requests to scripts, and do other tricky things. For example,
+to redirect all accesses to `.doc` files to a special script, do:
+
+    civetweb -url_rewrite_patterns **.doc$=/path/to/cgi-bin/handle_doc.cgi
+
+Or, to imitate support for user home directories, do:
+
+    civetweb -url_rewrite_patterns /~joe/=/home/joe/,/~bill=/home/bill/
+
+### hide\_files\_patterns
+A pattern for the files to hide. Files that match the pattern will not
+show up in directory listing and return `404 Not Found` if requested. Pattern
+must be for a file name only, not including directory names. Example:
+
+    civetweb -hide_files_patterns secret.txt|**.hide
+
+Note: hide\_file\_patterns uses the pattern described above. If you want to
+hide all files with a certain extension, make sure to use **.extension
+(not just *.extension).
+
+### request\_timeout\_ms `30000`
+Timeout for network read and network write operations, in milliseconds.
+If a client intends to keep long-running connection, either increase this
+value or (better) use keep-alive messages.
+
+### keep\_alive\_timeout\_ms `500` or `0`
+Idle timeout between two requests in one keep-alive connection.
+If keep alive is enabled, multiple requests using the same connection 
+are possible. This reduces the overhead for opening and closing connections
+when loading several resources from one server, but it also blocks one port
+and one thread at the server during the lifetime of this connection.
+Unfortunately, browsers do not close the keep-alive connection after loading
+all resources required to show a website.
+The server closes a keep-alive connection, if there is no additional request
+from the client during this timeout.
+
+Note: if enable\_keep\_alive is set to `no` the value of 
+keep\_alive\_timeout\_ms should be set to `0`, if enable\_keep\_alive is set 
+to `yes`, the value of keep\_alive\_timeout\_ms must be >0.
+Currently keep\_alive\_timeout\_ms is ignored if enable\_keep\_alive is no,
+but future versions my drop the enable\_keep\_alive configuration value and
+automatically use keep-alive if keep\_alive\_timeout\_ms is not 0.
+
+### linger\_timeout\_ms
+Set TCP socket linger timeout before closing sockets (SO\_LINGER option).
+The configured value is a timeout in milliseconds. Setting the value to 0
+will yield in abortive close (if the socket is closed from the server side).
+Setting the value to -1 will turn off linger.
+If the value is not set (or set to -2), CivetWeb will not set the linger
+option at all.
+
+Note: For consistency with other timeouts, the value is configured in
+milliseconds. However, the TCP socket layer usually only offers a timeout in 
+seconds, so the value should be an integer multiple of 1000.
+
+### lua\_preload\_file
+This configuration option can be used to specify a Lua script file, which
+is executed before the actual web page script (Lua script, Lua server page
+or Lua websocket). It can be used to modify the Lua environment of all web
+page scripts, e.g., by loading additional libraries or defining functions
+required by all scripts.
+It may be used to achieve backward compatibility by defining obsolete
+functions as well.
+
+### lua\_script\_pattern `"**.lua$`
+A pattern for files that are interpreted as Lua scripts by the server.
+In contrast to Lua server pages, Lua scripts use plain Lua syntax.
+An example can be found in the test directory.
+
+### lua\_server\_page\_pattern `**.lp$|**.lsp$`
+Files matching this pattern are treated as Lua server pages.
+In contrast to Lua scripts, the content of a Lua server pages is delivered
+directly to the client. Lua script parts are delimited from the standard
+content by including them between <? and ?> tags.
+An example can be found in the test directory.
+
+### lua\_background\_script
+Experimental feature, and subject to change.
+Run a Lua script in the background, independent from any connection.
+The script is started before network access to the server is available.
+It can be used to prepare the document root (e.g., update files, compress
+files, ...), check for external resources, remove old log files, etc.
+
+The Lua state remains open until the server is stopped.
+In the future, some callback functions will be available to notify the
+script on changes of the server state. See example lua script :
+[background.lua](https://github.com/civetweb/civetweb/blob/master/test/background.lua).
+
+Additional functions available in background script :
+sleep, root path, script name, isterminated
+
+### lua\_background\_script\_params `param1=1,param2=2`
+Can add dynamic parameters to background script.
+Parameters mapped to global 'mg' table 'params' field.
+
+### websocket\_root
+In case civetweb is built with Lua and websocket support, Lua scripts may
+be used for websockets as well. Since websockets use a different URL scheme
+(ws, wss) than other http pages (http, https), the Lua scripts used for
+websockets may also be served from a different directory. By default,
+the document_root is used as websocket_root as well.
+
+
+### access\_control\_allow\_origin `*`
+Access-Control-Allow-Origin header field, used for cross-origin resource
+sharing (CORS).
+See the [Wikipedia page on 
CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
+
+
+### access\_control\_allow\_methods `*`
+Access-Control-Allow-Methods header field, used for cross-origin resource
+sharing (CORS) pre-flight requests.
+See the [Wikipedia page on 
CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
+
+If set to an empty string, pre-flights will not be supported directly by the 
server,
+but scripts may still support pre-flights by handling the OPTIONS method 
properly.
+If set to "*", the pre-flight will allow whatever method has been requested.
+If set to a comma separated list of valid HTTP methods, the pre-flight will 
return
+exactly this list as allowed method.
+If set in any other way, the result is unspecified.
+
+
+### access\_control\_allow\_headers `*`
+Access-Control-Allow-Headers header field, used for cross-origin resource
+sharing (CORS) pre-flight requests.
+See the [Wikipedia page on 
CORS](http://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
+
+If set to an empty string, pre-flights will not allow additional headers.
+If set to "*", the pre-flight will allow whatever headers have been requested.
+If set to a comma separated list of valid HTTP headers, the pre-flight will 
return
+exactly this list as allowed headers.
+If set in any other way, the result is unspecified.
+
+
+### error\_pages
+This option may be used to specify a directory for user defined error pages.
+The error pages may be specified for an individual http status code (e.g.,
+404 - page requested by the client not found), a group of http status codes
+(e.g., 4xx - all client errors) or all errors. The corresponding error pages
+must be called error404.ext, error4xx.ext or error.ext, whereas the file
+extention may be one of the extentions specified for the index_files option.
+See the [Wikipedia page on HTTP status 
codes](http://en.wikipedia.org/wiki/HTTP_status_code).
+
+### tcp\_nodelay `0`
+Enable TCP_NODELAY socket option on client connections.
+
+If set the socket option will disable Nagle's algorithm on the connection
+which means that packets will be sent as soon as possible instead of waiting
+for a full buffer or timeout to occur.
+
+    0    Keep the default: Nagel's algorithm enabled
+    1    Disable Nagel's algorithm for all sockets
+
+### static\_file\_max\_age `3600`
+Set the maximum time (in seconds) a cache may store a static files.
+
+This option will set the `Cache-Control: max-age` value for static files.
+Dynamically generated content, i.e., content created by a script or callback,
+must send cache control headers by themselfes.
+
+A value >0 corresponds to a maximum allowed caching time in seconds.
+This value should not exceed one year (RFC 2616, Section 14.21).
+A value of 0 will send "do not cache" headers for all static files.
+For values <0 and values >31622400, the behavior is undefined.
+
+### strict\_transport\_security\_max\_age
+
+Set the `Strict-Transport-Security` header, and set the `max-age` value.
+This instructs web browsers to interact with the server only using HTTPS,
+never by HTTP. If set, it will be sent for every request handled directly
+by the server, except scripts (CGI, Lua, ..) and callbacks. They must 
+send HTTP headers on their own.
+
+The time is specified in seconds. If this configuration is not set, 
+or set to -1, no `Strict-Transport-Security` header will be sent.
+For values <-1 and values >31622400, the behavior is undefined.
+
+### decode\_url `yes`
+URL encoded request strings are decoded in the server, unless it is disabled
+by setting this option to `no`.
+
+### ssl\_verify\_peer `no`
+Enable client's certificate verification by the server.
+
+### ssl\_ca\_path
+Name of a directory containing trusted CA certificates. Each file in the
+directory must contain only a single CA certificate. The files must be named
+by the subject name’s hash and an extension of “.0”. If there is more 
than one
+certificate with the same subject name they should have extensions ".0", ".1",
+".2" and so on respectively.
+
+### ssl\_ca\_file
+Path to a .pem file containing trusted certificates. The file may contain
+more than one certificate.
+
+### ssl\_verify\_depth `9`
+Sets maximum depth of certificate chain. If client's certificate chain is 
longer
+than the depth set here connection is refused.
+
+### ssl\_default\_verify\_paths `yes`
+Loads default trusted certificates locations set at openssl compile time.
+
+### ssl\_cipher\_list
+List of ciphers to present to the client. Entries should be separated by
+colons, commas or spaces.
+
+    ALL           All available ciphers
+    ALL:!eNULL    All ciphers excluding NULL ciphers
+    AES128:!MD5   AES 128 with digests other than MD5
+
+See [this entry](https://www.openssl.org/docs/manmaster/apps/ciphers.html) in
+OpenSSL documentation for full list of options and additional examples.
+
+### ssl\_protocol\_version `0`
+Sets the minimal accepted version of SSL/TLS protocol according to the table:
+
+Protocols | Value
+------------ | -------------
+SSL2+SSL3+TLS1.0+TLS1.1+TLS1.2  | 0
+SSL3+TLS1.0+TLS1.1+TLS1.2  | 1
+TLS1.0+TLS1.1+TLS1.2 | 2
+TLS1.1+TLS1.2 | 3
+TLS1.2 | 4
+
+### ssl\_short\_trust `no`
+Enables the use of short lived certificates. This will allow for the 
certificates
+and keys specified in `ssl_certificate`, `ssl_ca_file` and `ssl_ca_path` to be
+exchanged and reloaded while the server is running.
+
+In an automated environment it is advised to first write the new pem file to
+a different filename and then to rename it to the configured pem file name to
+increase performance while swapping the certificate.
+
+Disk IO performance can be improved when keeping the certificates and keys 
stored
+on a tmpfs (linux) on a system with very high throughput.
+
+### allow\_sendfile\_call `yes`
+This option can be used to enable or disable the use of the Linux `sendfile` 
system call. It is only available for Linux systems and only affecting HTTP 
(not HTTPS) connections if `throttle` is not enabled. While using the 
`sendfile` call will lead to a performance boost for HTTP connections, this 
call may be broken for some file systems and some operating system versions.
+
+### case\_sensitive `no`
+This option can be uset to enable case URLs for Windows servers. It is only 
available for Windows systems. Windows file systems are not case sensitive, but 
they still store the file name including case. If this option is set to `yes`, 
the comparison for URIs and Windows file names will be case sensitive.
+
+### allow\_index\_script\_resource `no`
+Index scripts (like `index.cgi` or `index.lua`) may have script handled 
resources.
+
+It this feature is activated, that /some/path/file.ext might be handled by:
+  1. /some/path/file.ext (with PATH\_INFO='/', if ext = cgi)
+  2. /some/path/index.lua with mg.request\_info.path\_info='/file.ext'
+  3. /some/path/index.cgi with PATH\_INFO='/file.ext'
+  4. /some/path/index.php with PATH\_INFO='/file.ext'
+  5. /some/index.lua with mg.request\_info.path\_info=='/path/file.ext'
+  6. /some/index.cgi with PATH\_INFO='/path/file.ext'
+  7. /some/index.php with PATH\_INFO='/path/file.ext'
+  8. /index.lua with mg.request\_info.path\_info=='/some/path/file.ext'
+  9. /index.cgi with PATH\_INFO='/some/path/file.ext'
+  10. /index.php with PATH\_INFO='/some/path/file.ext'
+
+Note: This example is valid, if the default configuration values for 
`index_files`, `cgi_pattern` and `lua_script_pattern` are used, and the server 
is built with CGI and Lua support enabled.
+
+If this feature is not activated, only the first file (/some/path/file.cgi) 
will be accepted.
+
+Note: This parameter affects only index scripts. A path like 
/here/script.cgi/handle/this.ext will call /here/script.cgi with 
PATH\_INFO='/handle/this.ext', no matter if this option is set to `yes` or 
`no`. 
+
+This feature can be used to completely hide the script extension from the URL.
+
+### additional\_header
+Send additional HTTP response header line for every request.
+The full header line including key and value must be specified, excluding the 
carriage return line feed.
+
+Example (used as command line option): 
+`-additional_header "X-Frame-Options: SAMEORIGIN"`
+
+This option can be specified multiple times. All specified header lines will 
be sent.
+
+# Lua Scripts and Lua Server Pages
+Pre-built Windows and Mac civetweb binaries have built-in Lua scripting
+support as well as support for Lua Server Pages.
+
+Lua scripts (default extension: *.lua) use plain Lua syntax.
+The body of the script file is not sent directly to the client,
+the Lua script must send header and content of the web page by calling
+the function mg.write(text).
+
+Lua Server Pages (default extensions: *.lsp, *.lp) are html pages containing
+script elements similar to PHP, using the Lua programming language instead of
+PHP. Lua script elements must be enclosed in `<?  ?>` blocks, and can appear
+anywhere on the page. Furthermore, Lua Server Pages offer the opportunity to
+insert the content of a variable by enclosing the Lua variable name in
+`<?=  ?>` blocks, similar to PHP.
+For example, to print the current weekday name and the URI of the current
+page, one can write:
+
+    <p>
+      <span>Today is:</span>
+      <? mg.write(os.date("%A")) ?>
+    </p>
+    <p>
+      URI is <?=mg.request_info.uri?>
+    </p>
+
+Lua is known for it's speed and small size. Civetweb currently uses Lua
+version 5.2.4. The documentation for it can be found in the
+[Lua 5.2 reference manual](http://www.lua.org/manual/5.2/).
+
+
+Note that this example uses function `mg.write()`, which sends data to the
+web client. Using `mg.write()` is the way to generate web content from inside
+Lua code. In addition to `mg.write()`, all standard Lua library functions
+are accessible from the Lua code (please check the reference manual for
+details). Lua functions working on files (e.g., `io.open`) use a path
+relative to the working path of the civetweb process. The web server content
+is located in the path `mg.document_root`.
+Information on the request is available in the `mg.request_info`
+object, like the request method, all HTTP headers, etcetera.
+
+[page2.lua](https://github.com/civetweb/civetweb/blob/master/test/page2.lua)
+is an example for a plain Lua script.
+
+[page2.lp](https://github.com/civetweb/civetweb/blob/master/test/page2.lp)
+is an example for a Lua Server Page.
+
+Both examples show the content of the `mg.request_info` object as the page
+content. Please refer to `struct mg_request_info` definition in
+[civetweb.h](https://github.com/civetweb/civetweb/blob/master/include/civetweb.h)
+to see additional information on the elements of the `mg.request_info` object.
+
+Civetweb also provides access to the [SQlite3 database](http://www.sqlite.org/)
+through the [LuaSQLite3 
interface](http://lua.sqlite.org/index.cgi/doc/tip/doc/lsqlite3.wiki)
+in Lua. Examples are given in
+[page.lua](https://github.com/civetweb/civetweb/blob/master/test/page.lua) and
+[page.lp](https://github.com/civetweb/civetweb/blob/master/test/page.lp).
+
+
+Civetweb exports the following functions to Lua:
+
+mg (table):
+
+    mg.read()                  -- reads a chunk from POST data, returns it as 
a string
+    mg.write(str)              -- writes string to the client
+    mg.include(filename, [pathtype]) -- include another Lua Page file (Lua 
Pages only)
+                               -- pathtype can be "abs", "rel"/"file" or 
"virt[ual]"
+                               -- like defined for SSI #include
+    mg.redirect(uri)           -- internal redirect to a given URI
+    mg.onerror(msg)            -- error handler, can be overridden
+    mg.version                 -- a string that holds Civetweb version
+    mg.document_root           -- a string that holds the document root 
directory
+    mg.auth_domain             -- a string that holds the HTTP authentication 
domain
+    mg.get_var(str, varname)   -- extract variable from (query) string
+    mg.get_cookie(str, cookie) -- extract cookie from a string
+    mg.get_mime_type(filename) -- get MIME type of a file
+    mg.get_info(infotype)      -- get server status information
+    mg.send_file(filename)     -- send a file, including MIME type
+    mg.url_encode(str)         -- URL encode a string
+    mg.url_decode(str, [form]) -- URL decode a string. If form=true, replace + 
by space.
+    mg.base64_encode(str)      -- BASE64 encode a string
+    mg.base64_decode(str)      -- BASE64 decode a string
+    mg.md5(str)                -- return the MD5 hash of a string
+    mg.keep_alive(bool)        -- allow/forbid to use http keep-alive for this 
request
+    mg.request_info            -- a table with the following request 
information
+         .remote_addr          -- IP address of the client as string
+         .remote_port          -- remote port number
+         .server_port          -- server port number
+         .request_method       -- HTTP method (e.g.: GET, POST)
+         .http_version         -- HTTP protocol version (e.g.: 1.1)
+         .uri                  -- resource name
+         .query_string         -- query string if present, nil otherwise
+         .script_name          -- name of the Lua script
+         .https                -- true if accessed by https://, false otherwise
+         .remote_user          -- user name if authenticated, nil otherwise
+
+connect (function):
+
+    -- Connect to the remote TCP server. This function is an implementation
+    -- of simple socket interface. It returns a socket object with three
+    -- methods: send, recv, close, which are synchronous (blocking).
+    -- connect() throws an exception on connection error.
+    connect(host, port, use_ssl)
+
+    -- Example of using connect() interface:
+    local host = 'code.google.com'  -- IP address or domain name
+    local ok, sock = pcall(connect, host, 80, 1)
+    if ok then
+      sock:send('GET /p/civetweb/ HTTP/1.0\r\n' ..
+                'Host: ' .. host .. '\r\n\r\n')
+      local reply = sock:recv()
+      sock:close()
+      -- reply now contains the web page https://code.google.com/p/civetweb
+    end
+
+
+All filename arguments are either absolute or relative to the civetweb working
+directory (not the document root or the Lua script/page file).
+    
+**IMPORTANT: Civetweb does not send HTTP headers for Lua pages. Therefore,
+every Lua Page must begin with a HTTP reply line and headers**, like this:
+
+    <? mg.write('HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n') ?>
+    <html><body>
+      ... the rest of the web page ...
+
+To serve a Lua Page, civetweb creates a Lua context. That context is used for
+all Lua blocks within the page. That means, all Lua blocks on the same page
+share the same context. If one block defines a variable, for example, that
+variable is visible in all block that follow.
+
+## Websockets for Lua
+Civetweb offers support for websockets in Lua as well. In contrast to plain
+Lua scripts and Lua server pages, Lua websocket scripts are shared by all 
clients.
+
+Lua websocket scripts must define a few functions:
+    open(arg)    -- callback to accept or reject a connection
+    ready(arg)   -- called after a connection has been established
+    data(arg)    -- called when the server receives data from the client
+    close(arg)   -- called when a websocket connection is closed
+All function are called with one argument of type table with at least one field
+"client" to identify the client. When "open" is called, the argument table 
additionally
+contains the "request_info" table as defined above. For the "data" handler, an
+additional field "data" is available. The functions "open", "ready" and "data"
+must return true in order to keep the connetion open.
+
+Lua websocket pages do support single shot (timeout) and interval timers.
+
+An example is shown in
+[websocket.lua](https://github.com/civetweb/civetweb/blob/master/test/websocket.lua).
+
+
+# Common Problems
+- PHP doesn't work - getting empty page, or 'File not found' error. The
+  reason for that is wrong paths to the interpreter. Remember that with PHP,
+  the correct interpreter is `php-cgi.exe` (`php-cgi` on UNIX).
+  Solution: specify the full path to the PHP interpreter, e.g.:
+    `civetweb -cgi_interpreter /full/path/to/php-cgi`
+
+- `php-cgi` is unavailable, for example on Mac OS X. As long as the `php` 
binary is installed, you can run CGI programs in command line mode (see the 
example below). Note that in this mode, `$_GET` and friends will be 
unavailable, and you'll have to parse the query string manually using 
[parse_str](http://php.net/manual/en/function.parse-str.php) and the 
`QUERY_STRING` environmental variable.
+
+        #!/usr/bin/php
+        <?php
+        echo "Content-Type: text/html\r\n\r\n";
+        echo "Hello World!\n";
+        ?>
+
+- Civetweb fails to start. If Civetweb exits immediately when started, this
+  usually indicates a syntax error in the configuration file
+  (named `civetweb.conf` by default) or the command-line arguments.
+  Syntax checking is omitted from Civetweb to keep its size low. However,
+  the Manual should be of help. Note: the syntax changes from time to time,
+  so updating the config file might be necessary after executable update.
+
+- Embedding with OpenSSL on Windows might fail because of calling convention.
+  To force Civetweb to use `__stdcall` convention, add `/Gz` compilation
+  flag in Visual Studio compiler.
+

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/_config.yml
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/_config.yml 
b/thirdparty/civetweb-1.10/docs/_config.yml
new file mode 100644
index 0000000..259a24e
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/_config.yml
@@ -0,0 +1 @@
+theme: jekyll-theme-tactile
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/api/mg_callbacks.md
----------------------------------------------------------------------
diff --git a/thirdparty/civetweb-1.10/docs/api/mg_callbacks.md 
b/thirdparty/civetweb-1.10/docs/api/mg_callbacks.md
new file mode 100644
index 0000000..c7d69a1
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/api/mg_callbacks.md
@@ -0,0 +1,60 @@
+# Civetweb API Reference
+
+### `struct mg_callbacks;`
+
+### Fields
+
+| Field | Description |
+| :--- | :--- |
+|**`begin_request`**|**`int (*begin_request)( struct mg_connection *conn );`**|
+| |The `begin_request()` callback function is called when CivetWeb has 
received a new HTTP request. If the callback function does not process the 
request, it should return 0. In that case CivetWeb will handle the request with 
the default callback routine. If the callback function returns a value between 
1 and 999, CivetWeb does nothing and the callback function should do all the 
processing, including sending the proper HTTP headers etc. Starting at CivetWeb 
version 1.7, the function `begin_request()` is called before any authorization 
is done. If an authorization check is required, `request_handler()` should be 
used instead. The return value of the callback function is not only used to 
signal CivetWeb to not further process the request. The returned value is also 
stored as HTTP status code in the access log. |
+|**`connection_close`**|**`void (*connection_close)( const struct 
mg_connection *conn );`**|
+| |The callback function `connection_close()` is called when CivetWeb is 
closing a connection. The per-context mutex is locked when the callback 
function is invoked. The function is primarly useful for noting when a 
websocket is closing and removing it from any application-maintained list of 
clients. *Using this callback for websocket connections is deprecated. Use* 
`mg_set_websocket_handler()` *instead.*|
+|**`end_request`**|**`void (*end_request)(const struct mg_connection *conn, 
int reply_status_code);`**|
+| |The callback function `end_request()` is called by CivetWeb when a request 
has been completely processed. It sends the reply status code which was sent to 
the client to the application.|
+|**`exit_context`**|**`void (*exit_context)( const struct mg_context *ctx 
);`**|
+| |The callback function `exit_context()` is called by CivetWeb when the 
server is stopped. It allows the application to do some cleanup on the 
application side.|
+|**`http_error`**|**`int (*http_error)( struct mg_connection *conn, int status 
);`**|
+| |The callback function `http_error()` is called by CivetWeb just before an 
HTTP error is to be sent to the client. The function allows the application to 
send a custom error page. The status code of the error is provided as a 
parameter. If the application sends their own error page, it must return 1 to 
signal CivetWeb that no further processing is needed. If the returned value is 
0, CivetWeb will send a built-in error page to the client.|
+|**`init_context`**|**`void (*init_context)( const struct mg_context *ctx 
);`**|
+| |The callback function `init_context()` is called after the CivetWeb server 
has been started and initialized, but before any requests are served. This 
allowes the application to perform some initialization activities before the 
first requests are handled.|
+|**`init_lua`**|**`void (*init_lua)( const struct mg_connection *conn, void 
*lua_context );`**|
+| |The callback function `init_lua()` is called just before a Lua server page 
is to be served. Lua page serving must have been enabled at compile time for 
this callback function to be called. The parameter `lua_context` is a 
`lua_State *` pointer.|
+|**`init_ssl`**|**`int (*init_ssl)( void *ssl_context, void *user_data );`**|
+| |The callback function `init_ssl()` is called when CivetWeb initializes the 
SSL library. The parameter `user_data` contains a pointer to the data which was 
provided to `mg_start()` when the server was started. The callback function can 
return 0 to signal that CivetWeb should setup the SSL certificate. With a 
return value of 1 the callback function signals CivetWeb that the certificate 
has already been setup and no further processing is necessary. The value -1 
should be returned when the SSL initialization fails.|
+|**`init_thread`**|**`void (*init_thread)( const struct mg_context *ctx, int 
thread_type );`**|
+| |The callback function `init_thread()` is called when a new thread is 
created by CivetWeb. The `thread_type` parameter indicates which type of thread 
has been created. following thread types are recognized:|
+| |**0** - The master thread is created |
+| |**1** - A worker thread which handles client connections has been created|
+| |**2** - An internal helper thread (timer thread) has been created|
+|**`log_access`**|**`int (*log_access)( const struct mg_connection *conn, 
const char *message );`**|
+| |The callback function `log_access()` is called when CivetWeb is about to 
log a message. If the callback function returns 0, CivetWeb will use the 
default internal access log routines to log the access. If a non-zero value is 
returned, CivetWeb assumes that access logging has already been done and no 
further action is performed.|
+|**`log_message`**|**`int (*log_message)( const struct mg_connection *conn, 
const char *message );`**|
+| |The callback function `log_message()` is called when CivetWeb is about to 
log a message. If the callback function returns 0, CivetWeb will use the 
default internal log routines to log the message. If a non-zero value is 
returned CivetWeb assumes that logging has already been done and no further 
action is performed.|
+|**`open_file`**|**`const char *(*open_file)( const struct mg_connection 
*conn, const char *path, size_t *data_len );`**|
+| |The callback function `open_file()` is called when a file is to be opened 
by CivetWeb. The callback can return a pointer to a memory location and set the 
memory block size in the variable pointed to by `data_len` to signal CivetWeb 
that the file should not be loaded from disk, but that instead a stored version 
in memory should be used. If the callback function returns NULL, CivetWeb will 
open the file from disk. This callback allows caching to be implemented at the 
application side, or to serve specific files from static memory instead of from 
disk.|
+|~~`upload`~~|**`void (*upload)( struct mg_connection * conn, const char 
*file_name );`**|
+| |*Deprecated. Use* `mg_handle_form_request()` *instead.* The callback 
function `upload()` is called when CivetWeb has uploaded a file to a temporary 
directory as result of a call to `mg_upload()`. The parameter `file_name` 
contains the full file name including path to the uploaded file.|
+|~~`websocket_connect`~~|**`int (*websocket_connect)( const struct 
mg_connection *conn );`**|
+| |*Deprecated. Use* `mg_set_websocket_handler()` *instead.* The callback 
function `websocket_connect()` is called when a websocket request is received, 
before the actual websocket handshake has taken place. The callback function 
can signal to CivetWeb if it should accept or deny the incoming request with 
one of the following return values: |
+| |**0** - CivetWeb can proceed with the handshake to accept the connection |
+| |**1** - CivetWeb must close the connection immediately without performing a 
handshake |
+|~~`websocket_data`~~|**`int (*websocket_data)( struct mg_connection *conn, 
int bits, char *data, size_t data_len );`**|
+| |*Deprecated. Use* `mg_set_websocket_handler()` *instead.* The callback 
function `websocket_data()` is called when a data frame has been received from 
the client. The parameters contain the following information: |
+| | **`bits`** - The first byte of the websocket frame. See 
[RFC-6455](http://tools.ietf.org/html/rfc6455) at section 5.2 for more 
information. |
+| | **`data`** - The pointer to the received data block. Masks--if any--have 
already been applied. |
+| | **`data_len`** - The length of the received data block |
+| | If the application wants to keep the websocket open to receive more data, 
the callback function should return the value **1**. If the value **0** is 
returned by the callback function, CivetWeb will close the websocket connection 
and no more frames will be received.|
+|~~`websocket_ready`~~|**`int (*websocket_ready)( struct mg_connection *conn 
);`**|
+| |*Deprecated. Use* `mg_set_websocket_handler()` *instead.* The callback 
function `websocket_ready()` is called after the handshake of a websocket 
connection has succeeded succesfully to signal the application that the 
connection is ready for use. |
+
+### Description
+
+Much of the functionality in the Civetweb library is provided through callback 
functions. The application registers their own processing functions with the 
Civetweb library and when an event happens, the appropriate callback function 
is called. In this way an application is able to have their processing code 
right at the heart of the webserver, without the need to change the code of the 
webserver itself. A number of callback functions are registered when the 
civetweb subsystem is started. Other may be added or changed at runtime with 
helper functions.
+
+A pointer to a `mg_callbacks` structure is passed as parameter to the 
[`mg_start()`](mg_start.md) function to provide links to callback functions 
which the webserver will call at specific events. If a specific callback 
function is not supplied, CivetWeb will fallback to default internal callback 
routines. Callback functions give the application detailed control over how 
specific events should be handled.
+
+### See Also
+
+* [`mg_start();`](mg_start.md)
+* [`mg_stop();`](mg_stop.md)

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/df353561/thirdparty/civetweb-1.10/docs/api/mg_check_digest_access_authentication.md
----------------------------------------------------------------------
diff --git 
a/thirdparty/civetweb-1.10/docs/api/mg_check_digest_access_authentication.md 
b/thirdparty/civetweb-1.10/docs/api/mg_check_digest_access_authentication.md
new file mode 100644
index 0000000..fec3ad3
--- /dev/null
+++ b/thirdparty/civetweb-1.10/docs/api/mg_check_digest_access_authentication.md
@@ -0,0 +1,37 @@
+# Civetweb API Reference
+
+### `mg_check_digest_access_authentication( conn, realm, filename );`
+
+### Parameters
+
+| Parameter | Type | Description |
+| :--- | :--- | :--- |
+|**`conn`**|`struct mg_connection *`| A pointer to the connection to be used 
to send data |
+|**`realm`**|`const char *`| The requested authentication realm or NULL |
+|**`filename`**|`const char *`| The path to the passwords file |
+
+### Return Value
+
+| Type | Description |
+| :--- | :--- |
+|`int`| An integer indicating success or failure |
+
+### Description
+
+This function can be used to check if a request header contains HTTP digest 
authentication
+information, matching user and password encoded within the password file.
+If the authentication realm (also called authentication domain) is NULL, the 
parameter
+`authentication_domain` as specified in the server configuration 
(`mg_start()`) is used.
+
+A positive return value means, the user name, realm and a correct password 
hash have been
+found in the passwords file.
+A return of 0 means, reading the password file succeeded, but there was no 
matching user,
+realm and password.
+The function returns a negative number on errors.
+
+### See Also
+
+* 
[`mg_send_digest_access_authentication_request();`](mg_send_digest_access_authentication_request.md)
+* [`mg_modify_passwords_file();`](mg_modify_passwords_file.md)
+* [`mg_start();`](mg_start.md)
+

Reply via email to