commit cd1ab8768da87d6986f6493a72a86b315fdb70d4
parent 2b583e7140b8b6a04769e861507ea212b8ac2817
Author: Sebastian Gerhardt <sebgerhardt@gmx.net>
Date: Thu, 4 Sep 2008 14:26:49 +0000
some typos in tutorial
Diffstat:
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/doc/chapters/largerpost.inc b/doc/chapters/largerpost.inc
@@ -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 @@ clients concurrently uploading, responding with a proper busy message if necessa
@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 @@ const char* fileexistspage = "<html><body>This file already exists.</body></html
@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
-@code{send_page} 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
+@code{send_page} 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 @@ become clear later.
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 @@ int answer_to_connection (void *cls, struct MHD_Connection *connection, const ch
@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 @@ the structure is initialized to "no error".
@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 @@ constituted no expected request method.
@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 @@ con_info->answercode = MHD_HTTP_INTERNAL_SERVER_ERROR;
@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 @@ if (size > 0)
@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 @@ This is essentially the whole example @code{largepost.c}.
@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.
