xavi/libweb/doc/man7/libweb_http.7, branch chunkSmall and lightweight web framework written in C99 and POSIX.1-2008.
https://gitea.privatedns.org/xavi/libweb/atom?h=chunk2025-10-06T14:27:21+00:00libweb_http.7: Add note about HTTP responses2025-10-06T14:27:21+00:00Xavier Del Campo Romeroxavi92@disroot.org2025-10-06T14:27:21+00:00urn:sha1:4918cf87d3cf5d3dd8425fe10d97a06282472df6Fix design issues with async responses, add async example2025-10-06T13:51:00+00:00Xavier Del Campo Romeroxavi92@disroot.org2025-10-05T23:23:20+00:00urn:sha1:3e4c7c993bbbe2bdeb563fa888b900d01c4be4a1
struct http_response did not provide users any void * that could be used
to maintain a state between calls to an asynchronous HTTP response.
On the other hand, the user pointer could not be used for this purpose,
since it is shared among all HTTP clients for a given struct handler
instance.
Moreover, the length callback was still not supporting this feature,
which in fact might be required by some users. Implementing this was
particularly challenging, as this broke the current assumption that
all bytes on a call to http_read were being processed.
Now, since a client request can only be partially processed because of
the length callback, http_read must take this into account so that the
remaining bytes are still available for future calls, before reading
again from the file descriptor.
Implement async HTTP responses2025-09-24T10:33:35+00:00Xavier Del Campo Romeroxavi92@disroot.org2025-09-23T20:03:57+00:00urn:sha1:5a6f30440b66fe6713acb9d979dc3e6624e4c36a
Sometimes, library users cannot return a HTTP response as soon as the
request is received, or the operations that are required to generate it
can take a long time.
In order to solve this, libweb adds a new member to struct
http_response, namely step, which must be assigned to a function
whenever a HTTP response should be generated in a non-blocking manner.
Leaving the function pointer as null will fall back to the default
behaviour.
Bump version to 0.4.02024-08-22T00:27:35+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-08-22T00:04:29+00:00urn:sha1:93571556ee97e1a3e1829f8bc708d1d63f188840Bump version to 0.3.02024-02-19T22:33:27+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-02-19T22:29:01+00:00urn:sha1:b4930f72bb9026c5a0871f4fa4cabe20cb0e6a9fLimit maximum multipart/form-data pairs and files2024-02-19T22:00:56+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-02-19T22:00:56+00:00urn:sha1:afe0681c0b26bb64bad55d7e86770f346cfa043e
A malicious user could inject an infinite number of empty files or
key/value pairs into a request in order to exhaust the device's
resources.
Bump version to 0.2.02024-02-12T22:12:43+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-02-12T20:21:57+00:00urn:sha1:6ceae16a20175edb77fb2ffab0d3d6648d011221libweb_http.7: Update according to status quo2024-02-12T22:00:03+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-02-12T21:44:47+00:00urn:sha1:edc855f93b10aebc7afc71749ba2e86c73b1b77cUpdate copyright notices to 20242024-02-12T21:45:17+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-02-12T21:16:35+00:00urn:sha1:fcba916011f8fe21e60df1e0302371fc3956126fSend HTTP headers to payload callback2023-11-18T00:03:12+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-11-17T23:56:04+00:00urn:sha1:65031ca3502e0c27780be847fd97c112546741a9
Even if libweb already parses some common headers, such as
Content-Length, some users might find it interesting to inspect which
headers were received from a request.
Since HTTP/1.1 does not define a limit on the number of maximum headers
a client can send, for security reasons a maximum value must be provided
by the user. Any extra headers shall be then discarded by libweb.
An example application showing this new feature is also provided.