[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r12347 - libmicrohttpd-docs/WWW
From: |
gnunet |
Subject: |
[GNUnet-SVN] r12347 - libmicrohttpd-docs/WWW |
Date: |
Mon, 26 Jul 2010 19:01:02 +0200 |
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 "100 CONTINUE" response. MHD
+Clients should never create a "100 CONTINUE" response. MHD
handles "100 CONTINUE" 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)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r12347 - libmicrohttpd-docs/WWW,
gnunet <=