Still there is an issue with re-open a file. Patch applied below to avoid it.
Also iterate_post() always returns MHD_OK, because the app's logic driven from the value of con_info->answercode(). And in case if fwrite() fails we also update the answer code & page and MHD_post_process() overwrite them (fileioerror becomes postprocerror). May be I am wrong here, but I see this in this way. Offtopic: Are there plans to "say" libmicrohttpd to "clear" network buffers when something goes wrong and we are ready to send a response? Currently, my fears about reading the whole request was confirmed (in case of largepost.c the answer_to_connection() function will be called as many times as needed). diff --git a/doc/examples/largepost.c b/doc/examples/largepost.c index 6846a536..3fa8efa6 100644 --- a/doc/examples/largepost.c +++ b/doc/examples/largepost.c @@ -138,6 +138,9 @@ iterate_post (void *coninfo_cls, if (! con_info->fp) { + if (0 != con_info->answercode) /* something went wrong */ + return MHD_YES; + if (NULL != (fp = fopen (filename, "rb"))) { fclose (fp); @@ -161,7 +164,7 @@ iterate_post (void *coninfo_cls, { con_info->answerstring = fileioerror; con_info->answercode = MHD_HTTP_INTERNAL_SERVER_ERROR; - return MHD_NO; + return MHD_YES; } } @@ -324,8 +327,10 @@ main () &answer_to_connection, NULL, MHD_OPTION_NOTIFY_COMPLETED, &request_completed, NULL, MHD_OPTION_END); - if (NULL == daemon) + if (NULL == daemon) { + fprintf (stderr, "failed to start daemon\n"); return 1; + } (void) getchar (); MHD_stop_daemon (daemon); return 0; Thanks! -- With Best Regards, Vitaliy V. Tokarev