some typos in tutorial

author: Sebastian Gerhardt <sebgerhardt@gmx.net> 2008-09-04 14:26:49 +0000
committer: Sebastian Gerhardt <sebgerhardt@gmx.net> 2008-09-04 14:26:49 +0000
commit: cd1ab8768da87d6986f6493a72a86b315fdb70d4 (patch)
tree: 5119c9817faa5b1c589e055735fe106d1749b339 /doc/chapters
parent: 2b583e7140b8b6a04769e861507ea212b8ac2817 (diff)
download: libmicrohttpd-cd1ab8768da87d6986f6493a72a86b315fdb70d4.tar.gz
libmicrohttpd-cd1ab8768da87d6986f6493a72a86b315fdb70d4.zip
1 files changed, 19 insertions, 19 deletions
diff --git a/doc/chapters/largerpost.inc b/doc/chapters/largerpost.inc
index dd3f9d6f..07e62470 100644
--- 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 a request is too slow. One of these variables that needs to be shared for all connections is the
-of clients which are uploading.
+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,   
+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 for uploading. 
+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} 
+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 
+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. 
+@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
+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 needs one.
+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
+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,
+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.
author	Sebastian Gerhardt <sebgerhardt@gmx.net>	2008-09-04 14:26:49 +0000
committer	Sebastian Gerhardt <sebgerhardt@gmx.net>	2008-09-04 14:26:49 +0000
commit	cd1ab8768da87d6986f6493a72a86b315fdb70d4 (patch)
tree	5119c9817faa5b1c589e055735fe106d1749b339 /doc/chapters
parent	2b583e7140b8b6a04769e861507ea212b8ac2817 (diff)
download	libmicrohttpd-cd1ab8768da87d6986f6493a72a86b315fdb70d4.tar.gz libmicrohttpd-cd1ab8768da87d6986f6493a72a86b315fdb70d4.zip

diff --git a/doc/chapters/largerpost.inc b/doc/chapters/largerpost.inc index dd3f9d6f..07e62470 100644 --- a/doc/chapters/largerpost.inc +++ b/doc/chapters/largerpost.inc
@@ -1,7 +1,7 @@
1	--- NOTE: This does not work flawlessly with the beta release because there is	1	--- NOTE: This does not work flawlessly with the beta release because there is
2	a bug preventing early busy messages from being sent ---	2	a bug preventing early busy messages from being sent ---
3		3
4	The previous chapter introduced a way to upload data to the server but the developed example program	4	The previous chapter introduced a way to upload data to the server, but the developed example program
5	has some shortcomings, such as not being able to handle larger chunks of data. In this chapter, we	5	has some shortcomings, such as not being able to handle larger chunks of data. In this chapter, we
6	are going to discuss a more advanced server program that allows clients to upload a file in order to	6	are going to discuss a more advanced server program that allows clients to upload a file in order to
7	have it stored on the server's filesystem. The server shall also watch and limit the number of	7	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
11	@heading Prepared answers	11	@heading Prepared answers
12	We choose to operate the server with the @code{SELECT_INTERNALLY} method. This makes it easier to	12	We choose to operate the server with the @code{SELECT_INTERNALLY} method. This makes it easier to
13	synchronize the global states at the cost of possible delays for other connections if the processing	13	synchronize the global states at the cost of possible delays for other connections if the processing
14	of a request is to slow. A variable that needs to be shared for all connections is the total number	14	of a request is too slow. One of these variables that needs to be shared for all connections is the
15	of clients which are uploading.	15	total number of clients that are uploading.
16		16
17	@verbatim	17	@verbatim
18	#define MAXCLIENTS 2	18	#define MAXCLIENTS 2
19	static unsigned char nr_of_uploading_clients = 0;	19	static unsigned char nr_of_uploading_clients = 0;
20	@end verbatim	20	@end verbatim
21	@noindent	21	@noindent
22		22
23	If there are too many clients uploading, we want the server to respond to all requests with a busy	23	If there are too many clients uploading, we want the server to respond to all requests with a busy
24	message	24	message.
25	@verbatim	25	@verbatim
26	const char* busypage = "<html><body>This server is busy, please try again later.</body></html>";	26	const char* busypage = "<html><body>This server is busy, please try again later.</body></html>";
27	@end verbatim	27	@end verbatim
28	@noindent	28	@noindent
29		29
30	Otherwise, the server will send a form that informs the user of the current number of uploading clients,	30	Otherwise, the server will send a @emph{form} that informs the user of the current number of uploading clients,
31	and ask her to pick a file on her local filesystem for uploading.	31	and ask her to pick a file on her local filesystem which is to be uploaded.
32	@verbatim	32	@verbatim
33	const char* askpage = "<html><body>\n\	33	const char* askpage = "<html><body>\n\
34	Upload a file, please!<br>\n\	34	Upload a file, please!<br>\n\
@@ -54,9 +54,9 @@ const char* fileexistspage = "<html><body>This file already exists.</body></html
54	@end verbatim	54	@end verbatim
55	@noindent	55	@noindent
56		56
57	It would be tolerable to send all these responses undifferentiated with an @code{200 HTTP_OK}	57	It would be tolerable to send all these responses undifferentiated with a @code{200 HTTP_OK}
58	status code, but in order to improve the @code{HTTP} conformance of our server a bit, we extend the	58	status code but in order to improve the @code{HTTP} conformance of our server a bit, we extend the
59	@code{send_page} function so that it allows to chose individual status codes.	59	@code{send_page} function so that it accepts individual status codes.
60		60
61	@verbatim	61	@verbatim
62	int send_page (struct MHD_Connection connection, const char page, int status_code)	62	int send_page (struct MHD_Connection connection, const char page, int status_code)
@@ -84,7 +84,7 @@ become clear later.
84	The decision whether the server is busy or not is made right at the beginning of the connection. To	84	The decision whether the server is busy or not is made right at the beginning of the connection. To
85	do that at this stage is especially important for @emph{POST} requests because if no response is	85	do that at this stage is especially important for @emph{POST} requests because if no response is
86	queued at this point, and @code{MHD_YES} returned, @emph{MHD} will not sent any queued messages until	86	queued at this point, and @code{MHD_YES} returned, @emph{MHD} will not sent any queued messages until
87	a postprocessor has been created and the post iterator was called at least once.	87	a postprocessor has been created and the post iterator is called at least once.
88		88
89	@verbatim	89	@verbatim
90	int answer_to_connection (void cls, struct MHD_Connection connection, const char *url,	90	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
101	@noindent	101	@noindent
102		102
103	If the server is not busy, the @code{connection_info} structure is initialized as usual, with	103	If the server is not busy, the @code{connection_info} structure is initialized as usual, with
104	an additional filepointer for each connection.	104	the addition of a filepointer for each connection.
105		105
106	@verbatim	106	@verbatim
107	con_info = malloc (sizeof (struct connection_info_struct));	107	con_info = malloc (sizeof (struct connection_info_struct));
@@ -150,8 +150,8 @@ the structure is initialized to "no error".
150	@noindent	150	@noindent
151		151
152	If the connection handler is called for the second time, @emph{GET} requests will be answered with	152	If the connection handler is called for the second time, @emph{GET} requests will be answered with
153	the form. We can keep the buffer under function scope because we have asked @emph{MHD} to make its	153	the @emph{form}. We can keep the buffer under function scope, because we asked @emph{MHD} to make its
154	own copy of it for as long as it needs one.	154	own copy of it for as long as it is needed.
155	@verbatim	155	@verbatim
156	if (0 == strcmp (method, "GET"))	156	if (0 == strcmp (method, "GET"))
157	{	157	{
@@ -191,8 +191,8 @@ constituted no expected request method.
191		191
192		192
193	@heading Storing to data	193	@heading Storing to data
194	Unlike the @code{simplepost.c} example, it is to be expected that post iterator will be called	194	Unlike the @code{simplepost.c} example, here it is to be expected that post iterator will be called
195	several times now. This means that for any given connection, there might be several concurrent of them,	195	several times now. This means that for any given connection (there might be several concurrent of them)
196	the posted data has to be written to the correct file. That is why we store a file handle in every	196	the posted data has to be written to the correct file. That is why we store a file handle in every
197	@code{connection_info}, so that the it is preserved between successive iterations.	197	@code{connection_info}, so that the it is preserved between successive iterations.
198	@verbatim	198	@verbatim
@@ -213,7 +213,7 @@ con_info->answercode = MHD_HTTP_INTERNAL_SERVER_ERROR;
213	@end verbatim	213	@end verbatim
214	@noindent	214	@noindent
215		215
216	In the "askpage" form, we told the client to label its post data with the "file" key. Anything else	216	In the "askpage" @emph{form}, we told the client to label its post data with the "file" key. Anything else
217	would be an error.	217	would be an error.
218		218
219	@verbatim	219	@verbatim
@@ -253,7 +253,7 @@ if (size > 0)
253	@end verbatim	253	@end verbatim
254	@noindent	254	@noindent
255		255
256	If this point has been reached, everything worked flawless for this iteration and the response can	256	If this point has been reached, everything worked well for this iteration and the response can
257	be set to success again. If the upload has finished, this iterator function will not be called again.	257	be set to success again. If the upload has finished, this iterator function will not be called again.
258	@verbatim	258	@verbatim
259	con_info->answerstring = completepage;	259	con_info->answerstring = completepage;
@@ -299,4 +299,4 @@ This is essentially the whole example @code{largepost.c}.
299	@heading Remarks	299	@heading Remarks
300	Now that the clients are able to create files on the server, security aspects are becoming even more	300	Now that the clients are able to create files on the server, security aspects are becoming even more
301	important than before. Aside from proper client authentication, the server should always make sure	301	important than before. Aside from proper client authentication, the server should always make sure
302	explicitly that no files will be written outside a dedicated upload directory.	302	explicitly that no files will be created outside of a dedicated upload directory.