[GNUnet-SVN] r12347 - libmicrohttpd-docs/WWW

[gnunet]

Author: grothoff
Date: 2010-07-26 19:01:02 +0200 (Mon, 26 Jul 2010)
New Revision: 12347

Modified:
   libmicrohttpd-docs/WWW/index.html
   libmicrohttpd-docs/WWW/microhttpd.pdf
   libmicrohttpd-docs/WWW/tutorial.pdf
Log:
update

Modified: libmicrohttpd-docs/WWW/index.html
===================================================================
--- libmicrohttpd-docs/WWW/index.html   2010-07-26 17:00:40 UTC (rev 12346)
+++ libmicrohttpd-docs/WWW/index.html   2010-07-26 17:01:02 UTC (rev 12347)
@@ -9,7 +9,7 @@
 <meta name="robots" content="index,follow">
 <meta name="revisit-after" content="28 days">
 <meta name="publisher" content="Christian Grothoff">
-<meta name="date" content="2009-2-14">
+<meta name="date" content="2010-7-26">
 <meta name="rights" content="(C) 2007, 2008, 2009, 2010 by Christian 
Grothoff>";
 <meta http-equiv="expires" content="43200">
 </head>
@@ -26,12 +26,12 @@
 <ul>
 <li>C library: fast and small</li>
 <li>API is simple, expressive and fully reentrant</li>
-<li>Implementation is http 1.1 compliant</li>
+<li>Implementation is HTTP 1.1 compliant</li>
 <li>HTTP server can listen on multiple ports</li>
 <li>Support for IPv6</li>
 <li>Support for incremental processing of POST data</li>
-<li>Creates binary of only 30k (without TLS/SSL support)</li>
-<li>Three different threading models</li>
+<li>Creates binary of only 32k (without TLS/SSL support)</li>
+<li>Four different threading models (select, poll, pthread, thread pool)</li>
 <li>Supported platforms include GNU/Linux, FreeBSD, OpenBSD, NetBSD, 
    OS X, W32, Symbian and z/OS</li>
 <li>Optional support for SSL3 and TLS (requires libgcrypt and libgnutls)</li>
@@ -40,7 +40,7 @@
 a concurrent HTTP server to other projects.  Existing alternatives
 were either non-free, not reentrant, standalone, of terrible code
 quality or a combination thereof.  Do not use libmicrohttpd if you are
-looking for a standalone http server, there are many other projects
+looking for a standalone HTTP server, there are many other projects
 out there that provide that kind of functionality already.  However,
 if you want to be able to serve simple WWW pages from within your C or
 C++ application, check it out.
@@ -143,6 +143,8 @@
       *ptr = &dummy;
       return MHD_YES;
     }
+  if (0 != *upload_data_size)
+    return MHD_NO; /* upload data in a GET!? */
   *ptr = NULL; /* clear context pointer */
   response = MHD_create_response_from_data(strlen(page),
                                           (void*) page,
@@ -158,8 +160,8 @@
 int main(int argc,
         char ** argv) {
   struct MHD_Daemon * d;
-  if (argc != 3) {
-    printf("%s PORT SECONDS-TO-RUN\n",
+  if (argc != 2) {
+    printf("%s PORT\n",
           argv[0]);
     return 1;
   }
@@ -172,7 +174,7 @@
                       MHD_OPTION_END);
   if (d == NULL)
     return 1;
-  sleep(atoi(argv[2]));
+  (void) getc ();
   MHD_stop_daemon(d);
   return 0;
 }
@@ -211,11 +213,12 @@
 callback, or the last model if you want to use a more event-driven
 model with one big select loop.
 <br>
-As a special scalability feature, MHD offers the use of a thread pool
-with the <tt>MHD_USE_SELECT_INTERNALLY</tt> mode.  As said before, by
-default this mode only uses a single thread.  With the thread pool
-option, it is possible to handle multiple connections with multiple
-threads.  The number of threads is specified using the 
+The third model combines a thread pool with
+the <tt>MHD_USE_SELECT_INTERNALLY</tt> mode, which can benefit
+implementations that require scalability. As said before, by default
+this mode only uses a single thread.  With the thread pool option, it
+is possible to handle multiple connections with multiple threads.  The
+number of threads is specified using the
 <tt>MHD_OPTION_THREAD_POOL_SIZE</tt>; any value greater than one for
 this option will activate the use of the thread pool.  In contrast to
 the <tt>MHD_USE_THREAD_PER_CONNECTION</tt> mode (where each thread
@@ -226,7 +229,7 @@
 operation for MHD.
 </p>
 <p >
-The third threading model (used when no specific flag is given), uses
+The fourth threading model (used when no specific flag is given), uses
 no threads.  Instead, the main application must (periodically) request
 file descriptor sets from MHD, perform a select call and then call
 <tt>MHD_run</tt>.  <tt>MHD_run</tt> will then process HTTP requests as
@@ -242,22 +245,25 @@
 provide response data (this only happens in this mode).
 </p>
 <p >
-The testcases provided include examples for using each of the three
+The testcases provided include examples for using each of the 
 threading modes.
 </p>
 <h3>Responses</h3>
 <p >
 MHD provides various functions to create <tt>struct MHD_Response</tt>
 objects.  A response consists of a set of HTTP headers and a (possibly
-empty) body.  The two main ways to create a response are either by
+empty) body.  The three main ways to create a response are either by
 specifying a given (fixed-size) body
-(<tt>MHD_create_response_from_data</tt>) or by providing a function of
+(<tt>MHD_create_response_from_data</tt>), by providing a function of
 type <tt>MHD_ContentReaderCallback</tt> which provides portions of the
-response as needed.  The first response construction is great for
-small and in particular static webpages that fit into memory.  The
-second response type should be used for response objects where the
-size is initially not known or where the response maybe too large to
-fit into memory.
+response as needed or by providing an open file descriptor
+(<tt>MHD_create_response_from_fd</tt>).  The first response
+construction is great for small and in particular static webpages that
+fit into memory.  The second response type should be used for response
+objects where the size is initially not known or where the response
+maybe too large to fit into memory.  Finally, using a file descriptor
+can be used on Linux systems to use the highly efficient
+<tt>sendfile</tt> call for the file transfer.
 </p>
 <p >
 A response is used by calling <tt>MHD_queue_response</tt> which sends
@@ -268,20 +274,21 @@
 call <tt>MHD_destroy_response</tt> when a response object is no longer
 needed, that is, the server will not call <tt>MHD_queue_response</tt>
 again using this response object.  Note that this does not mean that
-the response will be immediately destroyed -- destruction maybe
+the response will be immediately destroyed -- destruction may be
 delayed until sending of the response is complete on all connections
 that have the response in the queue.
 </p>
+<h3>Queueing responses</h3>
 <p >
-Clients should never queue a &#34;100 CONTINUE&#34; response.  MHD
+Clients should never create a &#34;100 CONTINUE&#34; response.  MHD
 handles &#34;100 CONTINUE&#34; internally and only allows clients to
 queue a single response per connection.  Furthermore, clients must not
-queue a response before the request has been fully received.  If a
+queue a response before the request has been fully received (except
+in the case of rejecting PUT or POST operations in HTTP 1.1).  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>).
 </p>
-<h3>Queueing responses</h3>
 <p >
 The callback function for the respective URL will be called at least
 twice.  The first call happens after the server has received the
@@ -335,15 +342,16 @@
 <h2>Bugtrack</h2>
 <p >
 libmicrohttpd uses Mantis for bugtracking.  Visit <a
-href="https://gnunet.org/mantis/";>https://gnunet.org/mantis/</a> to
+href="https://gnunet.org/bugs/";>https://gnunet.org/bugs/</a> to
 report bugs.  You need to sign up for a reporter account.  Please make
 sure you report bugs under <strong>libmicrohttpd</strong> and not
 under any of the other projects.
 </p>
 <p >
-If you dislike Mantis and need to report a bug contact <a
-href="mailto:address@hidden";>address@hidden</a> via
-e-mail.
+For questions and discussions please use the
+<a href="http://mailman.gnu.org/mailman/listinfo/libmicrohttpd";>GNU 
libmicrohttpd mailinglist</a>.
+Messages to the list from non-subscribers are subject to manual moderation 
+and are hence likely to be delayed significantly.
 </p>
 
 <a name="users"></a>
@@ -353,7 +361,7 @@
 let us know so that we can add you to the list!
 </p>
 <ul>
-<li><a href="http://gnunet.org/";>GNUnet</a></li>
+<li><a href="https://gnunet.org/";>GNUnet</a></li>
 <li><a href="http://www.sarine.nl/gmpc";>Gnome Music Player Client</a></li>
 <li><a href="http://code.google.com/p/freeciv-forever/";>Freeciv 
Forever</a></li>
 <li><a href="http://code.google.com/p/callhome/";>CallHome</a></li>
@@ -365,6 +373,10 @@
 
 <a name="alternatives"></a>
 <h2>Alternatives</h2>
+<p>
+If you are aware of a competing library that might be a better fit for
+some developers, please let us know so that we can add it to the list!
+</p>
 <ul>
 <li><a href="http://www.pion.org/projects/pion-network-library";>Pion Network 
Library (C++)</a></li>
 <li><a href="http://www.hughes.com.au/products/libhttpd/";>libhttpd (C)</a></li>
@@ -374,6 +386,15 @@
 <li><a href="http://www.nightmare.com/medusa/";>Medusa (Python)</a></li>
 <li><a href="http://mihl.sourceforge.net/";>mihl (C)</a></li>
 </ul>
+
+<a name="funding"></a>
+<h2>Funding</h2>
+<p>
+GNU libmicrohttpd development is currently funded in part by
+the <a href="http://www.dfg.de/";>Deutsche Forschungsgemeinschaft</a>
+under ENP GR 3688/1-1.
+</p>
+
 <hr/>
 <address><a href="mailto:address@hidden";>Christian Grothoff</a></address>
 <pre>

Modified: libmicrohttpd-docs/WWW/microhttpd.pdf
===================================================================
(Binary files differ)

Modified: libmicrohttpd-docs/WWW/tutorial.pdf
===================================================================
(Binary files differ)