Re: [libmicrohttpd] feature request: get connection_timeout value from MHD_Connection structure

[Vitaliy T]

On 15 March 2017 at 12:58, Evgeny Grin <address@hidden> wrote:
> Why do you want to play with timeout during connection suspend?
> Function description explicitly state:
> "Suspended connections will NOT time out; timeouts will restart when the
> connection handling is resumed."

That's right. This is why after resuming a connection and if it is
timed outed because the MHD thinks so.
There is only one place where MHD send the INTERNAL_ERROR message:

src/microhttpd/connection.c

     1358 static void
     1359 MHD_connection_update_event_loop_info (struct MHD_Connection
*connection)
     1360 {
     1361   while (1)
     1362     {
...
     1408         case MHD_CONNECTION_CONTINUE_SENT:
     1409           if (connection->read_buffer_offset ==
connection->read_buffer_size)
     1410             {
     1411               if ((MHD_YES != try_grow_read_buffer (connection)) &&
     1412                   (0 != (connection->daemon->options &
     1413                          MHD_USE_INTERNAL_POLLING_THREAD)))
     1414                 {
     1415                   /* failed to grow the read buffer, and the
     1416                      client which is supposed to handle the
     1417                      received data in a *blocking* fashion
     1418                      (in this mode) did not handle the data as
     1419                      it was supposed to!
     1420                      => we would either have to do busy-waiting
     1421                      (on the client, which would likely fail),
     1422                      or if we do nothing, we would just timeout
     1423                      on the connection (if a timeout is even
     1424                      set!).
     1425                      Solution: we kill the connection with an error */
     1426                   transmit_error_response (connection,
     1427
MHD_HTTP_INTERNAL_SERVER_ERROR,
     1428                                            INTERNAL_ERROR);
     1429                   continue;
     1430                 }
     1431             }

A TCP connection might be active and clients are waiting for
responses. But MHD thinks its smarter then a man :) No offend.

> Could you describe in details: what do you want to get, how did you
> start MHD and what is not working?

The idea is that the server is able to handle only one POST (upload
file) request per a time from clients. Others clients are suspended
when there is at least one active upload.

Suspending/resuming is a practical recommended by the Reference Manual.

I want to suspend a connection by some amount of time which may vary
per a program basis. Current implementation sets timeout to 0 before
suspending the connection. Otherwise, as I said previously, in case if
the connection is timed out, then MHD will send a response with the
hardcoded text above.

Setting the connection timeout to 0 leads to problems for clients:
1. They just closing a connection by its own timeout value.
2. The server might have time to send response to a suspended client if

Why I want to get/set connection timeout per a connection basis?

1. Because, it is simpler then writing more code than the task requires.
2. Because there is a function to set connection timeout and none to
get one's value.

I can implement the get function in my program easily. I just asked
for a feature request. If you see that is useless, then ok, just say
so. I will not be disappointed much.

I suppose we may close the question in the next way. I will implement
everything as I want, e.g. will made local patch to MHD and will test
within some kind amount of time (weeks, months). And in the case if I
would like see this feature in MHD-core I will send a patch.

Ok?

> In one thread you are asking about external polling, in another - about
> timeout and suspend/resume. Are those questions connected or independent
> situations?

I am working on one MHD project at the moment. All questions are
connected with each other.
There is a strong connection between suspend/resume and a connection
timeout, see above.

-- 
With Best Regards,
Vitaliy V. Tokarev