- added API documentation to libmicrohttpd.texi
- added websocket tutorial chapter to libmicrohttpd-tutorial and an much easier example for the tutorial
- added additional helper functions to ease the HTTP websocket handshake
- the code can now be compiled on Linux without errors
- changed sha1.c and sha1.h to the files provided by Evgeny (I replaced those files in src/microhttpd_ws/ with the files from src/microhttpd/ - maybe there is a smarter way...?)
- removed dependency for "htons" and "htonl" (these functions are now implemented in MHD_websocket.c; no need for OS-dependent files anymore)
- added an additional test script for testing of the library with any webbrowser (for manual practice test)
- several bugfixes
- parameters renamed
- special things clarified (fragmentation, RNG for client mode)
The new version of the API is at some points incompatible with the old version, but since it was in an experimental phase and it didn't compile on Linux, I guess this shouldn't bother anyone.
From my point of view, I am now finished with the library and it could go out of experimental.
Implemented the new function, related framework, and tests for iovec-based
responses.
The implementation is based on the patch provided by Lawrence Sebald and
Damon N. Earp from NASA.
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.
Evgeny Grin (Karlson2k)
David Gausmann
Christian Grothoff
silvioprog
ng0
Tim Rühsen