<feed xmlns='http://www.w3.org/2005/Atom'>
<title>xavi/libweb/handler.c, branch v0.5.0</title>
<subtitle>Small and lightweight web framework written in C99 and POSIX.1-2008.
</subtitle>
<id>https://gitea.privatedns.org/xavi/libweb/atom?h=v0.5.0</id>
<link rel='self' href='https://gitea.privatedns.org/xavi/libweb/atom?h=v0.5.0'/>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/'/>
<updated>2025-10-07T23:57:42+00:00</updated>
<entry>
<title>Implement HTTP chunk encoding</title>
<updated>2025-10-07T23:57:42+00:00</updated>
<author>
<name>Xavier Del Campo Romero</name>
<email>xavi92@disroot.org</email>
</author>
<published>2025-10-06T21:01:42+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=e77bd93693a74ce872d4c13fb45537c34518d84f'/>
<id>urn:sha1:e77bd93693a74ce872d4c13fb45537c34518d84f</id>
<content type='text'>
A new function pointer, namely chunk, has been added to struct
http_response so that library users can generate their message bodies
dynamically.
</content>
</entry>
<entry>
<title>Allow custom backlog connections</title>
<updated>2025-10-06T19:03:59+00:00</updated>
<author>
<name>Xavier Del Campo Romero</name>
<email>xavi92@disroot.org</email>
</author>
<published>2025-10-06T19:03:59+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=db9cb051c4ee05c07ab32dfed5bae8b7dc0916bd'/>
<id>urn:sha1:db9cb051c4ee05c07ab32dfed5bae8b7dc0916bd</id>
<content type='text'>
libweb calls listen(2) when setting up the HTTP server, and its backlog
argument was hardcoded to 10. While probably not an issue for some
applications, it can be too limiting for some others.

Therefore, it is desirable to allow library users to set up their own
limits. Otherwise, 10 is still chosen as a sane default.
</content>
</entry>
<entry>
<title>Fix design issues with async responses, add async example</title>
<updated>2025-10-06T13:51:00+00:00</updated>
<author>
<name>Xavier Del Campo Romero</name>
<email>xavi92@disroot.org</email>
</author>
<published>2025-10-05T23:23:20+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=3e4c7c993bbbe2bdeb563fa888b900d01c4be4a1'/>
<id>urn:sha1:3e4c7c993bbbe2bdeb563fa888b900d01c4be4a1</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Implement async HTTP responses</title>
<updated>2025-09-24T10:33:35+00:00</updated>
<author>
<name>Xavier Del Campo Romero</name>
<email>xavi92@disroot.org</email>
</author>
<published>2025-09-23T20:03:57+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=5a6f30440b66fe6713acb9d979dc3e6624e4c36a'/>
<id>urn:sha1:5a6f30440b66fe6713acb9d979dc3e6624e4c36a</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>handler.c: Do not printf when exiting</title>
<updated>2024-08-25T12:31:21+00:00</updated>
<author>
<name>Xavier Del Campo Romero</name>
<email>xavi.dcr@tutanota.com</email>
</author>
<published>2024-08-25T12:31:21+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=43a39a1f2e5e6c7c520f03293fc57aa76fea8aaf'/>
<id>urn:sha1:43a39a1f2e5e6c7c520f03293fc57aa76fea8aaf</id>
<content type='text'>
libweb is meant to be silent during normal operation, thus only printing
to stderr on errors.
</content>
</entry>
<entry>
<title>Move signal handling to processes</title>
<updated>2024-08-22T00:27:34+00:00</updated>
<author>
<name>Xavier Del Campo Romero</name>
<email>xavi.dcr@tutanota.com</email>
</author>
<published>2024-08-19T22:07:05+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=43e89fb23943b5ffb6854f290592c29cd079bf46'/>
<id>urn:sha1:43e89fb23943b5ffb6854f290592c29cd079bf46</id>
<content type='text'>
So far, libweb installed a signal handler so as to handle SIGTERM,
SIGPIPE and SIGINT signals so that processes would not have to care
about such details.

However, it is not advisable for libraries to install signal handlers,
as signals are handled on a per-process basis. The previous approach
would be incompatible if several instances of the library were allocated
by the same process.

Unfortunately, this has the undesired side effect of adding the
boilerplate code into the process.
</content>
</entry>
<entry>
<title>Limit maximum multipart/form-data pairs and files</title>
<updated>2024-02-19T22:00:56+00:00</updated>
<author>
<name>Xavier Del Campo Romero</name>
<email>xavi.dcr@tutanota.com</email>
</author>
<published>2024-02-19T22:00:56+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=afe0681c0b26bb64bad55d7e86770f346cfa043e'/>
<id>urn:sha1:afe0681c0b26bb64bad55d7e86770f346cfa043e</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Merge pull request 'Fix double-free on failed `server_client_close`' (#2) from midokura-xavi/libweb:fix-double-free into master</title>
<updated>2023-11-20T15:27:28+00:00</updated>
<author>
<name>xavi</name>
<email>xavi@noreply.localhost</email>
</author>
<published>2023-11-20T15:27:28+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=8f1ad3124e9e063ca0ee7c2548c747b20de3529d'/>
<id>urn:sha1:8f1ad3124e9e063ca0ee7c2548c747b20de3529d</id>
<content type='text'>
Reviewed-on: https://gitea.privatedns.org/xavi/libweb/pulls/2
</content>
</entry>
<entry>
<title>Fix double-free on failed server_client_close</title>
<updated>2023-11-20T15:25:58+00:00</updated>
<author>
<name>Xavier Del Campo</name>
<email>xavier.delcampo@midokura.com</email>
</author>
<published>2023-11-20T11:20:51+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=59a67a7541ee1559b140494c21a25b195246a4fa'/>
<id>urn:sha1:59a67a7541ee1559b140494c21a25b195246a4fa</id>
<content type='text'>
Even if server_client_close fails, it is needed for client_free to
remove the dangling reference from h-&gt;clients.
</content>
</entry>
<entry>
<title>Split handler_loop from handler_listen</title>
<updated>2023-11-20T15:06:19+00:00</updated>
<author>
<name>Xavier Del Campo</name>
<email>xavier.delcampo@midokura.com</email>
</author>
<published>2023-11-16T11:23:08+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/libweb/commit/?id=98f5f52461b0c1ab1ee3331722bd32e2db9e1d41'/>
<id>urn:sha1:98f5f52461b0c1ab1ee3331722bd32e2db9e1d41</id>
<content type='text'>
Some applications might set up a struct handler object to listen on any
port i.e., 0, but still need a way to determine which port number was
eventually selected by the implementation.

Therefore, handler_listen has been reduced to the server initialization
bit, whereas the main loop has been split into its own function, namely
handler_loop.

Because of these changes, it no longer made sense for libweb to write
the selected port to standard output, as this is something now
applications can do on their own.
</content>
</entry>
</feed>
