[GNUnet-SVN] r5628 - in libmicrohttpd-docs/WWW: . download

[gnunet]

Author: grothoff
Date: 2007-09-09 15:45:53 -0600 (Sun, 09 Sep 2007)
New Revision: 5628

Added:
   libmicrohttpd-docs/WWW/download/libmicrohttpd-0.1.0.tar.gz
Modified:
   libmicrohttpd-docs/WWW/index.php
Log:
release

Added: libmicrohttpd-docs/WWW/download/libmicrohttpd-0.1.0.tar.gz
===================================================================
(Binary files differ)


Property changes on: libmicrohttpd-docs/WWW/download/libmicrohttpd-0.1.0.tar.gz
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Modified: libmicrohttpd-docs/WWW/index.php
===================================================================
--- libmicrohttpd-docs/WWW/index.php    2007-09-09 21:32:12 UTC (rev 5627)
+++ libmicrohttpd-docs/WWW/index.php    2007-09-09 21:45:53 UTC (rev 5628)
@@ -34,7 +34,8 @@
 LI("Implementation is (largely) http 1.1 compliant");
 LI("HTTP server can listen on multiple ports");
 LI("Support for IPv6");
-LI("Creates binary of only 22k (for now)");
+LI("Support for incremental processing of POST data");
+LI("Creates binary of only 25k (for now)");
 LI("Three different threading models");
 echo "</ul>";
 W("libmicrohttpd was started because the author needed an easy way to add a 
concurrent HTTP server to other projects.");
@@ -50,7 +51,7 @@
 H2("Download");
 BP();
 W("You can find the current release %s.",
-  extlink_("download/libmicrohttpd-0.0.3.tar.gz", "here"));
+  extlink_("download/libmicrohttpd-0.1.0.tar.gz", "here"));
 W("The latest version can be obtained using");
 PRE("$ svn checkout https://gnunet.org/svn/libmicrohttpd/";);
 W("libmicrohttpd has no dependencies; however, the textcases use %s.",
@@ -86,7 +87,8 @@
                    const char * method,
                    const char * upload_data,
                    const char * version,
-                   unsigned int * upload_data_size) {
+                   unsigned int * upload_data_size,
+                    void ** unused) {
   const char * page = cls;
   struct MHD_Response * response;
   int ret;
@@ -128,6 +130,7 @@
 </pre>
 <?php
 EP();
+
 H3("Threading models");
 BP();
 W("The example above uses the simplest threading model, 
<tt>MHD_USE_THREAD_PER_CONNECTION</tt>.");
@@ -140,15 +143,20 @@
 W("Note that MHD will still start a single thread -- the main program can 
continue with its operations.");
 W("Naturally, if the HTTP server needs to interact with shared state in the 
main application, synchronization will be required.");
 W("If such synchronization in code providing a response results in blocking, 
all HTTP server operations on all connections will stall.");
+W("This mode is a bad choice if response data (for responses generated using 
the <tt>MHD_create_response_from_callback</tt> function) cannot always be 
provided instantly.");
+W("The reason is that the code generating responses should not block (since 
that would block all other connections) and on the other hand, if response data 
is not available immediately, MHD will start to busy wait on it.");
+W("Use the first model if you want to block on providing response data in the 
callback, or the last model if you want to use a more event-driven model with 
one big select loop.");
 P();
 W("The third threading model (used when no specific flag is given), uses no 
threads.");
 W("Instead, the main application must (periodically) request file descriptor 
sets from MHD, perform a select call and then call <tt>MHD_run</tt>.");
 W("<tt>MHD_run</tt> will then process HTTP requests as usual and return.");
 W("<tt>MHD_run</tt> is guaranteed to not block; however, access handlers and 
response processing callbacks that it invokes may block.");
 W("This mode is useful if a single-threaded implementation is desired and in 
particular if the main application already uses a select loop for its 
processing.");
+W("If the application is not ready to provide a response, it can just return 
zero for the number of bytes read and use its file descriptors in the external 
select loop to wake up and continue once the data is ready -- MHD will unlist 
the socket from the write set if the application failed to provide response 
data (this only happens in this mode).");
 P();
 W("The testcases provided include examples for using each of the three 
threading modes.");
 EP();
+
 H3("Responses");
 BP();
 W("MHD provides various functions to create <tt>struct MHD_Response</tt> 
objects.");
@@ -170,6 +178,25 @@
 W("If a client attempts to queue multiple responses or attempts to queue a 
response early, <tt>MHD_queue_response<tt> will fail (and return 
<tt>MHD_NO</tt>).");
 EP();
 
+H3("Parsing of POST requests");
+BP();
+W("MHD includes a set of three functions for parsing and processing data 
received in POST requests.");
+W("The functions allow incremental parsing and processing of POST data.");
+W("Only a tiny fraction of the overall POST data needs to fit into memory.");
+W("As a result, applications using MHD can support POST requests of arbitrary 
size.");
+W("POST data is processed by providing MHD with a callback function that is 
called on portions of the received values.");
+W("The POST parser itself is invoked repeatedly whenever more input bytes 
become available.");
+W("MHD supports both uri- and multipart/form-encoded POST data.");
+EP();
+
+H3("Memory Management");
+BP();
+W("The application can determine the size of buffers that MHD should use for 
handling of HTTP requests and parsing of POST data.");
+W("This way, MHD users can trade-off processing time and memory utilization.");
+W("Applications can limit the overall number of connections MHD will accept, 
as well as the total amount of memory used per connection.");
+W("MHD will gracefully handle all out-of-memory situations (by closing the 
connection and cleaning up any remaining state).");
+EP();
+
 ANCHOR("mantis");
 H2("Bugtrack");
 BP();