[GNUnet-SVN] r37103 - in libmicrohttpd: . doc

[gnunet]

Author: grothoff
Date: 2016-04-30 10:24:42 +0200 (Sat, 30 Apr 2016)
New Revision: 37103

Modified:
   libmicrohttpd/ChangeLog
   libmicrohttpd/doc/libmicrohttpd.texi
Log:
clarifications to manual re: [libmicrohttpd] MHD_ContentReaderCallback and Byte 
serving

Modified: libmicrohttpd/ChangeLog
===================================================================
--- libmicrohttpd/ChangeLog     2016-04-30 08:17:37 UTC (rev 37102)
+++ libmicrohttpd/ChangeLog     2016-04-30 08:24:42 UTC (rev 37103)
@@ -1,3 +1,6 @@
+Sat Apr 30 10:22:37 CEST 2016
+       Added clarifications to manual based on questions on list. -CG
+
 Sat Apr 23 20:12:01 CET 2016
        Tests perf_get_concurrent and test_concurrent_stop ported to use
        pthread instead of fork(). Added more error detections. -EG

Modified: libmicrohttpd/doc/libmicrohttpd.texi
===================================================================
--- libmicrohttpd/doc/libmicrohttpd.texi        2016-04-30 08:17:37 UTC (rev 
37102)
+++ libmicrohttpd/doc/libmicrohttpd.texi        2016-04-30 08:24:42 UTC (rev 
37103)
@@ -100,14 +100,24 @@
 
 The library is supposed to handle everything that it must handle
 (because the API would not allow clients to do this), such as basic
-connection management; however, detailed interpretations of headers ---
-such as range requests --- and HTTP methods are left to clients.  The
-library does understand @code{HEAD} and will only send the headers of
-the response and not the body, even if the client supplied a body.  The
-library also understands headers that control connection management
-(specifically, @code{Connection: close} and @code{Expect: 100 continue}
-are understood and handled automatically).
+connection management. However, detailed interpretations of headers,
+such as range requests, are left to the main application.  In
+particular, if an application developer wants to support range
+requests, he needs to explicitly indicate support in responses and
+also explicitly parse the range header and generate a response (for
+example, using the @code{MHD_create_response_from_fd_at_offset} call
+to serve ranges from a file).  MHD does understands headers that
+control connection management (specifically, @code{Connection: close}
+and @code{Expect: 100 continue} are understood and handled
+automatically).  @code{Connection: upgrade} is not yet supported.
 
+MHD also largely ignores the semantics of the different HTTP methods,
+so clients are left to handle those.  One exception is that MHD does
+understand @code{HEAD} and will only send the headers of the response
+and not the body, even if the client supplied a body.  (In fact,
+clients do need to construct a response with the correct length, even
+for @code{HEAD} request.)
+
 MHD understands @code{POST} data and is able to decode certain
 formats (at the moment only @code{application/x-www-form-urlencoded}
 and @code{multipart/form-data}) using the post processor API.  The