[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r7657 - libmicrohttpd/doc/chapters
From: |
gnunet |
Subject: |
[GNUnet-SVN] r7657 - libmicrohttpd/doc/chapters |
Date: |
Thu, 4 Sep 2008 08:26:50 -0600 (MDT) |
Author: sebdocwriter
Date: 2008-09-04 08:26:49 -0600 (Thu, 04 Sep 2008)
New Revision: 7657
Modified:
libmicrohttpd/doc/chapters/largerpost.inc
Log:
some typos in tutorial
Modified: libmicrohttpd/doc/chapters/largerpost.inc
===================================================================
--- libmicrohttpd/doc/chapters/largerpost.inc 2008-09-02 22:49:47 UTC (rev
7656)
+++ libmicrohttpd/doc/chapters/largerpost.inc 2008-09-04 14:26:49 UTC (rev
7657)
@@ -1,7 +1,7 @@
--- NOTE: This does not work flawlessly with the beta release because there is
a bug preventing early busy messages from being sent ---
-The previous chapter introduced a way to upload data to the server but the
developed example program
+The previous chapter introduced a way to upload data to the server, but the
developed example program
has some shortcomings, such as not being able to handle larger chunks of data.
In this chapter, we
are going to discuss a more advanced server program that allows clients to
upload a file in order to
have it stored on the server's filesystem. The server shall also watch and
limit the number of
@@ -11,24 +11,24 @@
@heading Prepared answers
We choose to operate the server with the @code{SELECT_INTERNALLY} method. This
makes it easier to
synchronize the global states at the cost of possible delays for other
connections if the processing
-of a request is to slow. A variable that needs to be shared for all
connections is the total number
-of clients which are uploading.
+of a request is too slow. One of these variables that needs to be shared for
all connections is the
+total number of clients that are uploading.
@verbatim
#define MAXCLIENTS 2
-static unsigned char nr_of_uploading_clients = 0;
+static unsigned char nr_of_uploading_clients = 0;
@end verbatim
@noindent
If there are too many clients uploading, we want the server to respond to all
requests with a busy
-message
+message.
@verbatim
const char* busypage = "<html><body>This server is busy, please try again
later.</body></html>";
@end verbatim
@noindent
-Otherwise, the server will send a form that informs the user of the current
number of uploading clients,
-and ask her to pick a file on her local filesystem for uploading.
+Otherwise, the server will send a @emph{form} that informs the user of the
current number of uploading clients,
+and ask her to pick a file on her local filesystem which is to be uploaded.
@verbatim
const char* askpage = "<html><body>\n\
Upload a file, please!<br>\n\
@@ -54,9 +54,9 @@
@end verbatim
@noindent
-It would be tolerable to send all these responses undifferentiated with an
@code{200 HTTP_OK}
-status code, but in order to improve the @code{HTTP} conformance of our server
a bit, we extend the
address@hidden function so that it allows to chose individual status codes.
+It would be tolerable to send all these responses undifferentiated with a
@code{200 HTTP_OK}
+status code but in order to improve the @code{HTTP} conformance of our server
a bit, we extend the
address@hidden function so that it accepts individual status codes.
@verbatim
int send_page (struct MHD_Connection *connection, const char* page, int
status_code)
@@ -84,7 +84,7 @@
The decision whether the server is busy or not is made right at the beginning
of the connection. To
do that at this stage is especially important for @emph{POST} requests because
if no response is
queued at this point, and @code{MHD_YES} returned, @emph{MHD} will not sent
any queued messages until
-a postprocessor has been created and the post iterator was called at least
once.
+a postprocessor has been created and the post iterator is called at least once.
@verbatim
int answer_to_connection (void *cls, struct MHD_Connection *connection, const
char *url,
@@ -101,7 +101,7 @@
@noindent
If the server is not busy, the @code{connection_info} structure is initialized
as usual, with
-an additional filepointer for each connection.
+the addition of a filepointer for each connection.
@verbatim
con_info = malloc (sizeof (struct connection_info_struct));
@@ -150,8 +150,8 @@
@noindent
If the connection handler is called for the second time, @emph{GET} requests
will be answered with
-the form. We can keep the buffer under function scope because we have asked
@emph{MHD} to make its
-own copy of it for as long as it needs one.
+the @emph{form}. We can keep the buffer under function scope, because we asked
@emph{MHD} to make its
+own copy of it for as long as it is needed.
@verbatim
if (0 == strcmp (method, "GET"))
{
@@ -191,8 +191,8 @@
@heading Storing to data
-Unlike the @code{simplepost.c} example, it is to be expected that post
iterator will be called
-several times now. This means that for any given connection, there might be
several concurrent of them,
+Unlike the @code{simplepost.c} example, here it is to be expected that post
iterator will be called
+several times now. This means that for any given connection (there might be
several concurrent of them)
the posted data has to be written to the correct file. That is why we store a
file handle in every
@code{connection_info}, so that the it is preserved between successive
iterations.
@verbatim
@@ -213,7 +213,7 @@
@end verbatim
@noindent
-In the "askpage" form, we told the client to label its post data with the
"file" key. Anything else
+In the "askpage" @emph{form}, we told the client to label its post data with
the "file" key. Anything else
would be an error.
@verbatim
@@ -253,7 +253,7 @@
@end verbatim
@noindent
-If this point has been reached, everything worked flawless for this iteration
and the response can
+If this point has been reached, everything worked well for this iteration and
the response can
be set to success again. If the upload has finished, this iterator function
will not be called again.
@verbatim
con_info->answerstring = completepage;
@@ -299,4 +299,4 @@
@heading Remarks
Now that the clients are able to create files on the server, security aspects
are becoming even more
important than before. Aside from proper client authentication, the server
should always make sure
-explicitly that no files will be written outside a dedicated upload directory.
+explicitly that no files will be created outside of a dedicated upload
directory.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r7657 - libmicrohttpd/doc/chapters,
gnunet <=