Lasa Martxel wrote:
Hello,
I have found the following code in daemon.c file, lines 1449 to 1467:
if (0 >= res)
{
if (GNUTLS_E_INTERRUPTED != res)
{
urh->app.celi &= ~MHD_EPOLL_STATE_WRITE_READY;
if (GNUTLS_E_INTERRUPTED != res)
(GNUTLS_E_INTERRUPTED != res) is checked twice.
In the read part (a few lines above), GNUTLS_E_INTERRUPTED != res is checked first and then GNUTLS_E_AGAIN != res. It looks like something similar should be done here, but I’m not sure.
Thanks,
Martxel
Date: Mon, 15 Oct 2018 14:11:39 +0200
Subject: [PATCH] Add response flag to force version to 1.0 and maintain
connection management.
The existing MHD_RF_HTTP_VERSION_1_0_ONLY flag already changes MHD's
behavior to apply HTTP 1.0 rules for connection management. When
enabled, MHD sends a response using the same version as used in the
request (is this normal?).
What I want is MHD responding as a HTTP 1.0 server with support for
connection management headers would do. This is what the
MHD_RF_HTTP_VERSION_1_0_RESPONSE response flag is for.
You can even combine it with MHD_RF_HTTP_VERSION_1_0_ONLY to change the
response's HTTP version while maintaining strict compliance with HTTP
1.0 regarding connection management.
This solution is not perfect as this flag is set on the response which
is created after header processing. So MHD will behave as a HTTP 1.1
server until the response is queued. It means that an invalid HTTP 1.1
request will fail even if the response is sent with HTTP 1.0 and the
request would be valid if interpreted with this version. For example,
this request will fail in strict mode:
GET /dummy HTTP/1.1
as the Host header is missing and is mandatory in HTTP 1.1, but it
should succeed when interpreted with HTTP 1.0.
I don't think this is a big issue in practice. Besides, being able to
change the HTTP version on a response basis is really convenient when
using MHD in a test framework where we need to validate a client against
HTTP 1.1 AND HTTP 1.0.
Thank you! Very cool to see the example working. Funny, I
implemented MHD_get_timeout in the main loop in my project but in all
my tests it always returned MHD_NO, so I assumed it was not applicable
to my use case and didn't include it in the example I wrote. But I
didn't make the connection that it *also* had to be called after
MHD_resume_connection until your response here. Would you consider
the attached patch? It adds one line to the docs that I'm quite sure
would have pointed me in the right direction had it been there before.
Thanks!
Bob
Christian Grothoff
Tim Rühsen
Evgeny Grin (Karlson2k)
silvioprog